similar to: Seeking clarification and way forward on limited scope variables.

Hi Sourabh, Thanks for raising this issue. To answer your question, (afaik) there isn’t anyone working on DW_AT_start_scope support in tree. We’re looking for a solution to this problem for Swift debugging, where it's important not to make a debug location for a variable available until its (guaranteed) initialization is complete. If at all possible, I’d /much/ rather we use the existing

> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that

Sorry, this is the attachment. 2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>: > Thank you. > > Here is an example and the attchment contains extra files including object > file and executable file. > I want to print for example the value of "a", but lldb command "frame > variable a" displays "0" and so does "b", and

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML

Hi, I would like to implement a fix to how LLVM handles/creates debug info for entities declared inside a basic block. Below you will find 5 parts: 1. Motivation for this fix. 2. Background explaining the cases that need to be fixed. 3. An example for each case. 4. Proposal on how to represent each case in dwarf. 5. Secondary (workaround) proposal which might be

On Mon, Dec 14, 2015 at 7:01 AM, Aboud, Amjad via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I verified that GDB 7.10 does support “DW_AT_abstract_origin” attribute on > “DW_TAG_lexical_block”. > I take it you mean that it does the right thing, finding the direct children of the abstract block when stepping into the inlined subroutine, etc? & this was a

Hi everyone, I'm trying to get debug information for a C/pthreads application, but it seems like clang/LLVM are producing limited & erroneous debugging information. I've attached a simple test example to reproduce the problem -- I'm using clang/LLVM 3.7.1 built from source on Ubuntu 14.04. I compile the attached file with: $ clang -O1 -g test.c -lpthread If I run: $ readelf

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

Hi I'm using llvm-5. Browsing the source of llvm-dwarfdump and trying it on some shared libraries, I see I can print the debug info (assuming it exists). For some function, I'm wondering if there's a short cut to prettyprinting the signature of a function in the library? I think, looking at the output, that enough information exists but it seems to involve looking at the subprogram

Let me try to summarize the implementation first. At the moment, there are two branches. 1. When an existing variable is optimized out and that variable is used to get the de-refereced value, pointed to by another pointer/reference variable. Such cases are being addressed using Dwarf expression DW_OP_implicit_pointer as de-referenced value of a pointer can be seen implicitly (using another

On Thu, Nov 14, 2019 at 1:27 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Nov 14, 2019, at 1:21 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Hey folks, > > > > Would you all mind having a bit of a design discussion around the > feature both at the DWARF level and the LLVM implementation? It seems like > what's

Hi all, I'm generating code using CLANG + LLVM 2.9 and would like to inspect formal parameter value for x86 32-bit when -O2 -g is used. It seems that when code is optimized by the compiler DWARF information generated doesn't allow to inspect value of parameter. Trying to inspect parameter value in GDB, parameter is marked as optimized by the compiler and thus I can't track its value.

Hi David, Happy new year ! I just uploaded a POC patch that covers the cases when pointer points to un-named variables using DW_OP_implicit_pointer (references and dynamic allocation). This is using artificial variable as suggested by Paul. https://reviews.llvm.org/D72055 I hope that now it should address your concerns. Scope of DW_OP_implicit_pointer: As we initially decided split of

On Thu, Mar 22, 2018 at 4:51 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: >> >> Adrian, >> >> Thanks for a quick reply! >> >> On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: >>> >>> >>>>

In the version of LLVM I'm using (Apple tag 2352.1), it seems that the DWARF emitter cannot produce DWARF location lists to outline when user variables live and where. Instead it uses a crutch of DW_AT_start_scope to specify each solitary location where an assignment to a user variable does occur. This is unsatisfactory for machines that put user variables in registers because it doesn't

Hi David, Excuse me for delayed answer. It took some time to prepare. Please, find the answers bellow... >Broad question: Do you have any specific motivation/users/etc in implementing this (if you can speak about it)? > - it might help motivate the work, understand what tradeoffs might be suitable for you/your users, etc. There are two general requirements: 1) Remove (or clean) invalid

On Thu, Mar 22, 2018 at 5:13 PM, Roman Levenstein via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Thu, Mar 22, 2018 at 4:51 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >> >>> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote: >>> >>> Adrian, >>> >>> Thanks for a quick reply!

Thank you, Clayton. This is very helpful. We use the LLDB specific GDB remote extensions, and our debugger server supports "qRegisterInfo" package. "reg 0x3c" is the frame pointer. In the example mentioned above, we have SP = FP - 40 for current call frame. And variable "a" is stored at address (FP + -24) from asm instruction [FP + -24] = R3;; Thus we can conclude

Adrian, Thanks for a quick reply! On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote: >> >> Hi, >> >> I'm trying to achieve the following: >> >> - I have a global variable BaseAddress that holds the base address of >> a