search for: dwarfv5

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...

...lists.llvm.org>; Jonas Devlieghere > <jdevlieghere at apple.com>; Robinson, Paul <paul.robinson at sony.com>; Eric > Christopher <echristo at gmail.com>; Frederic Riss <friss at apple.com> > Subject: Re: Increasing address pool reuse/reducing .o file size in > DWARFv5 > > I think this sounds like a good plan for Linux. I would like to see the > numbers for Darwin (= non-split DWARF) to decide whether we should just > make that the default. Eric's suggestion of having this committed as an > option first seems like a good step in that direction...

...mailto:paul.robinson at sony.com>>; Eric > > Christopher <echristo at gmail.com <mailto:echristo at gmail.com>>; Frederic Riss <friss at apple.com <mailto:friss at apple.com>> > > Subject: Re: Increasing address pool reuse/reducing .o file size in > > DWARFv5 > > > > I think this sounds like a good plan for Linux. I would like to see the > > numbers for Darwin (= non-split DWARF) to decide whether we should just > > make that the default. Eric's suggestion of having this committed as an > > option first seems like a go...

...nge & 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)', > > With Split DWARF or with DWARFv5 in LLVM at the moment, all addresses are indirected already. So it's: > > Replace "AT_low_pc (<indirection into a pool of addresses>)" with an "AT_low_pc (<indirection into a pool of addresses> + offset)". > >> s.t. the cost of a relocation for...

Hello all, I am implementing support for .debug_names section (which is introduced in DWARFv5 standard as replacement for .debug_pubnames and .debug_pubtypes). The question is: should usage of DWARF version 5 force generation of .debug_names instead of .debug_pubnames or we can make it just default behavior and provide user with the interface (cmd switch) to use other DWARFv5 features b...

...type > Type/item alignment > Defaulted template parameter > Atomic type modifier > DW_OP_implicit_pointer > .debug_macro section > Typed expressions > Supplementary objects > Ah, thanks for the list - mostly I'm interested in cases where Clang's output is not valid DWARFv5 when requested - the new features DWARFv5 enables/allows but doesn't require are lower priority to me. Which I don't think too much is left - DWARFv5 loclists in split DWARF is one I know of & might get to if someone else doesn't do it before me - I'm currently improving loclist...

Thanks, David for updating us. Regarding, mail address, can use anyone{@gmail or @amd}. but sourav0311 at gmail.com works best for me for mailing lists related stuff. Regarding, GDB side of DWARFv5 side of things, we've testing GDB-8.3 WRT DWARFv5 clang and gcc binaries to get better idea of debuggability of clang generated binaries with GDB. Primary motivation being GDB better handling of gcc generated binaries, compared to clang. We've been also tracking Ali's patches in gdb ma...

Hi llvm-dev, cfe-dev, It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention-- 1. Language aspects 2. Location mostly optimized out ones 3. DebugInfo conformance to DWARF-5 To avoid getting conflicted with some body

Hello folks, I was interested in the support we have for the attribute form DW_FORM_implicit_const (DWARFv5 feature) in clang/LLVM. And I had some doubts wrt this. I noticed that support for this was put in here in 2017: https://rev.ng/gitlab/revng-bar-2019/llvm/commit/d9df13befcbc702e239b650dd1f55778d72b8571 >From what I could make out, the support for generating DW_FORM_implicit_const is there...

Hello Everyone, I would like to have your thoughts on this. Overview of the problem =================== While implementing support for the DWARFv5 debug_macro section support in LLVM. I came across these holes: - The macros infrastructure in CLANG/LLVM is inherently tied to a particular version(v4 macinfo). For instance, consider this snippet from CLANG: Gen->getCGDebugInfo()->CreateMacro(getCurrentScope(), llvm::dwarf::DW_M...

Hi, Sorry for the late reply, I was OOO last week. > On Mar 29, 2018, at 3:59 PM, David Blaikie <dblaikie at gmail.com> wrote: > > +Eric Christopher +Adrian Prantl +Jonas Devlieghere (seems Jonas is doing a bunch of debug info work - guessing he's working with you, Adrian?) Yup, I joined Adrian’s team last August. > I'm guessing Eric's the most likely to have

On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > Ah, thanks for the list - mostly I'm interested in cases where Clang's > > output is not valid DWARFv5 when requested - the new features DWARFv5 > > enables/allows but doesn't require are lower priority to me. Which I > > don't think too much is left - DWARFv5 loclists in split DWARF is one > > I know of & might get to if someone else doesn't do it before me - I'...

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Pieb, > Wolfgang via llvm-dev > Sent: Wednesday, July 05, 2017 6:14 PM > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [DWARFv5] Reading the .debug_str_offsets section > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > > Robinson, Paul via llvm-dev > > Sent: Wednesday, July 05, 2017 1:35 PM > > To: llvm-dev at lists.llvm.org > &...

> > I'm guessing Eric's the most likely to have contacts over in GCC land to > maybe bridge the gap when talking about assembly syntax across the two. > Eric - any ideas how best to negotiate this pseudo-standard? (there's > another feature or two I'd like to propose too - at least to standardize > what the syntax /should/ be, even if gas doesn't support it

Hello all, it looks like we have a bug here but I am not sure. Currently if we have two similar types with implicit_const attributes and different values we end up with only one abbrev in .debug_abbrev section. For example consider two structures: S1 with implicit_const attribute ATTR and value VAL1 and S2 with implicit_const ATTR and value VAL2. The .debug_abbrev section will contain only 1

+Eric Christopher <echristo at gmail.com> +Adrian Prantl <aprantl at apple.com> +Jonas Devlieghere <jdevlieghere at apple.com> (seems Jonas is doing a bunch of debug info work - guessing he's working with you, Adrian?) I'm guessing Eric's the most likely to have contacts over in GCC land to maybe bridge the gap when talking about assembly syntax across the two. Eric

Yep, Wolfgang picked up on the one thing I saw too. This is why I like having people review my stuff. I think it's a bit of a pity that str_offsets_base can point into the middle of a str_offsets contribution in some ways Actually I changed my mind after saying that in the review, and in this writeup I concluded that it cannot do that. str_offsets_base points to the element immediately

...tle bit. - Dave > --paulr > > > > *From:* David Blaikie [mailto:dblaikie at gmail.com] > *Sent:* Thursday, March 29, 2018 10:59 AM > *To:* Robinson, Paul; Eric Christopher; Adrian Prantl; Jonas Devlieghere > *Cc:* llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] [DWARFv5] Assembler syntax for new line-table > features > > > > +Eric Christopher <echristo at gmail.com> +Adrian Prantl <aprantl at apple.com> > +Jonas Devlieghere <jdevlieghere at apple.com> (seems Jonas is doing a > bunch of debug info work - guessing he's wo...

There was some discussion about this in D34765, and I had a follow-up chat with Wolfgang separately, plus spent a fair amount of time in reading and thinking today. I thought I would write my understanding all down here so we can reach a common understanding of how it ought to work, and therefore what our code should do. For any non-DWARF-experts who might be interested, in principle this

>> To pass the MD5 checksum to the assembler, I added a new optional >> clause to the .file directive: >> md5 "checksum" >> where checksum is the 16-byte checksum in hex.  It's quoted because >> the assembler doesn't have a way to parse a 16-byte integer. > > I'd guess, long-term, that's probably not a great motivation for > choosing