Nat! via llvm-dev
2018-Jul-25 00:21 UTC
[llvm-dev] A question to the DWARF experts on symbol indirection
It would be great if some DWARF expert could weigh in on this, since my understanding on DWARF is rudimentary. Let's say I have a C function defined as struct ab { int a; int b; }; void fooWithAb( struct ab *_param) { } Is it possible to emit DWARF statements, so that in the debugger the parameter _param is hidden and the visibility is a and b, without a _param-> prefix ? Ciao Nat! Why I need this: https://www.mulle-kybernetik.com/weblog/2015/mulle_objc_meta_call_convention.html
Tim Northover via llvm-dev
2018-Jul-25 07:07 UTC
[llvm-dev] A question to the DWARF experts on symbol indirection
Hi Nat!, On Wed, 25 Jul 2018 at 01:21, Nat! via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Is it possible to emit DWARF statements, so that in the debugger the > parameter _param is hidden and the visibility is a and b, without a _param-> prefix ?It's certainly possible in LLVM IR. @llvm.dbg.declare and so on can associate arbitrary Values in a function with whatever name you want. But it looks like you're trying to convince Clang itself to do that. That's likely to be harder since it's not exactly a natural C mapping; I suspect a lot depends on just where you're doing your ABI lowering. Either way you're probably more likely to get a good response if you ask the question on the cfe-dev mailing list. Cheers. Tim.
via llvm-dev
2018-Jul-25 13:41 UTC
[llvm-dev] A question to the DWARF experts on symbol indirection
> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tim > Northover via llvm-dev > Sent: Wednesday, July 25, 2018 3:07 AM > To: Nat! > Cc: LLVM Developers Mailing List > Subject: Re: [llvm-dev] A question to the DWARF experts on symbol > indirection > > Hi Nat!, > > On Wed, 25 Jul 2018 at 01:21, Nat! via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > Is it possible to emit DWARF statements, so that in the debugger the > > parameter _param is hidden and the visibility is a and b, without a > _param-> prefix ? > > It's certainly possible in LLVM IR. @llvm.dbg.declare and so on can > associate arbitrary Values in a function with whatever name you want.DWARF expressions are certainly powerful enough to describe this.> > But it looks like you're trying to convince Clang itself to do that. > That's likely to be harder since it's not exactly a natural C mapping; > I suspect a lot depends on just where you're doing your ABI lowering.Also depends on whether you want your debugger to be able to call these functions. My guess is that you want to describe the formal parameter as artificial, using the proper struct description, so that calls work correctly. Then create local variables whose storage locations work indirectly off the (described as artificial) pointer parameter. Whether you get your modified front-end to do this, or hack up the backend, up to you. The question was *can* it be done, and the answer to that is clearly yes. --paulr> Either way you're probably more likely to get a good response if you > ask the question on the cfe-dev mailing list. > > Cheers. > > Tim. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Nat! via llvm-dev
2018-Jul-25 21:28 UTC
[llvm-dev] A question to the DWARF experts on symbol indirection
On 25.07.2018 09:07, Tim Northover wrote:> Hi Nat!, > > On Wed, 25 Jul 2018 at 01:21, Nat! via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Is it possible to emit DWARF statements, so that in the debugger the >> parameter _param is hidden and the visibility is a and b, without a _param-> prefix ? > It's certainly possible in LLVM IR. @llvm.dbg.declare and so on can > associate arbitrary Values in a function with whatever name you want.Thanks for this great tip! I tried this with some C derived and hacked IR code and the results are promising. The debugger finds the value (but can't print it, because it's not a legal C expression). But that should be OK, once my clang compiler is used to JIT the expression, or so I hope.> > But it looks like you're trying to convince Clang itself to do that. > That's likely to be harder since it's not exactly a natural C mapping;That part is fortunately already working. Ciao Nat!