similar to: Query/Suggestions on upgrading macro infrastructure.

Hi, I would like to implement macro debug info support in LLVM. Below you will find 4 parts: 1. Background on what does it mean to debug macros. 2. A brief explanation on how to represent macro debug info in DWARF 4.0. 3. The suggested design. 4. A full example: Source -> AST -> LLVM IR -> DWARF. Feel free to skip first two parts if you think you know the background.

> Do we really need to touch the AST? Or would it be reasonable to wire up the CGDebugInfo directly to the PPCallbacks, if it isn't already? (perhaps it is already wired up for other reasons?) This sound as a good idea, I will check that approach. PPCallbacks is only an interface, has nothing connected to it, but we will create a new class, which implement PPCallbacks, for macros. So we can

> Not necessarily, if we kept the macros in order in the list of macros attached to the CU, which I imagine we would. OK, now I understand what you are aiming for. I really do not favor one on the other. But, can you explain what is the advantage of the parent approach over the children approach? If any, the children approach seems to be the one reduces the LLVM IR size, is not it? Regards,

> Right - I was wondering if CGDebugInfo already implemented PPCallbacks or was otherwise being notified of PPCallback related things, possibly through a layer or two of indirection. I checked the approach of skipping representing macros in AST, and communicate them directly from Parser to CGDebugInfo. However, I could not find a way to initialize this communication. The only interface

On Mon, Nov 9, 2015 at 4:00 AM, Aboud, Amjad <amjad.aboud at intel.com> wrote: > I found a way to skip representing macros in AST and create them directly > in CGDebugInfo through PPCallbacks during preprocessing. > > To do that, I needed to extend ASTConsumer interface with this extra > method: > > > > /// If the consumer is interested in notifications from

On Fri, Nov 13, 2015 at 2:41 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Fri, Nov 13, 2015 at 10:21 AM, David Blaikie via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> On Mon, Nov 9, 2015 at 4:00 AM, Aboud, Amjad <amjad.aboud at intel.com> >> wrote: >> >>> I found a way to skip representing macros in AST and create them

I'd like to jump in. I do not work on a preprocessor based language, but have the same code expansion problem to encode. Right now, we hack around the problem by appending some prefix after the file name and pretend it is a different file, which is not great. I understand you want to represent expansion by DIFileMacro ? I'm not how this is supposed to be used and it is not in the example.

I think we have to be careful here. We might want flexibility to say "I want to use a specific class" without having to specify the exact DW_FORM. Sometimes, we might even end up in an ambiguous situation and not get the result we want. For example, in DWARFv4, the DW_AT_high_pc attribute has either a Constant or an Address class, which use completely different forms, but if we have just

On Wed, Nov 11, 2020 at 12:55 AM James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > > > On Wed, 11 Nov 2020 at 05:41, David Blaikie <dblaikie at gmail.com> wrote: >> >> +James for context too (always good to include the folks from the >> original threads for continuity) >> >> Yeah, my general attitude there was just twofold, one that

+James for context too (always good to include the folks from the original threads for continuity) Yeah, my general attitude there was just twofold, one that the discussion had strayed fairly far from the review (so interested parties might not see it, both because it's a targeted review thread on the noisy llvm-commits, and because fo the title not having much connection to the discussion)

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David > Blaikie via llvm-dev > Sent: Wednesday, November 11, 2020 12:46 PM > To: James Henderson <jh7370.2008 at my.bristol.ac.uk> > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [LLD] Support DWARF64, debug_info "sorting" > > On Wed, Nov 11,

(Adding back Cc: which got dropped) > (Igor - I don't know what happened, but your email split the mail thread in gmail for me.) The problem is that https://lists.llvm.org/pipermail/llvm-dev/2020-November/146528.html does not have an In-Reply-To: header. Added Igor to the Cc: list. If we go down the route (sorting DWARF64 after DWARF32), compared with a lightweight parse, I'd prefer

tl;dr: in DWARFv5, using DW_AT_ranges even when the range is contiguous reduces linked, uncompressed debug_addr size for optimized builds by 93% and reduces total .o file size (with compression and split) by 15%. It does grow .dwo file size a bit - DWARFv5, no compression, not split shows the net effect if all bytes are equal: -O3 clang binary grows by 0.4%, -O0 clang binary shrinks by 0.1% Should

Thanks Alexander for bringing this up! > The major drawback in sorting, is the need to parse DWARF, even a little bit > of it (only the first 4 bytes of a section to tell which version it is - first 12 if you > want to be able to jump over contributions and check /all/ contributions > coming from a given input object file (it might contain a combination of > DWARFv4 and DWARFv5)

I think I get it now, thanks for explaining! >> On Jan 12, 2020, at 11:44 AM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: >  > > >> On Fri, Jan 10, 2020 at 12:57 PM Vedant Kumar <vedant_kumar at apple.com> wrote: >> I don't totally follow the proposed encoding change & would appreciate a small example. >> >> Is the

I don't totally follow the proposed encoding change & would appreciate a small example. Is the idea to replace e.g. an 'AT_low_pc (<direct address>) + relocation for <direct address>' with an 'AT_low_pc (<indirection into a pool of addresses> + offset)', s.t. the cost of a relocation for the address is paid down the more it's used? How do you figure

Thanks for feedback. I agree with patch and numbers this will be a more concrete discussion, but I wanted to judge overall receptiveness to this approach and see maybe there was a better way. "Whilst the majority of objects will only have a single CU in them, there will be exceptions (LTO-generated objects, -r merged objects etc), so we do need to consider this approach." David can you

Hi Pavel, Thanks for your comments! On 5/21/20, Pavel Labath <pavel at labath.sk> wrote: > Hello Xing, > > I think the proposal looks very useful. I think it will be fairly tricky > to get all of the details right though. There is a lot of "inferring" > going on there, and getting that to work reliably and with predictable > results will need careful

On Wed, 11 Nov 2020 at 05:41, David Blaikie <dblaikie at gmail.com> wrote: > +James for context too (always good to include the folks from the > original threads for continuity) > > Yeah, my general attitude there was just twofold, one that the > discussion had strayed fairly far from the review (so interested > parties might not see it, both because it's a targeted

On some previous occasion that introduced additional indirection (don't remember the details) my debugger people groused about the additional performance cost of chasing down data in a different object-file section. So we (Sony) might be happier with low_pc as expressions, than with a ranges-always solution. But hard to say without data, and getting both modes in at least as a temporary