similar to: [DWARFv5] Assembler syntax for new line-table features

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. Also this is the same syntax Reid invented for the CodeView equivalent. To convey the root source filename, I allow the file number on the

On Thu, Mar 29, 2018 at 8:27 AM <paul.robinson at sony.com> wrote: > 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,

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

+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

FWIW I'm completely on board with everything Adrian has said in this thread :) -eric On Wed, Jan 17, 2018 at 11:00 AM Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > As mentioned by Adrian in the comment you linked, I too

Thank you for all the responses. Unfortunately I wasn't able to make any progress on creating the patches today. I'll be sure to add everyone who expressed interest here to the phabricator diff once I have them ready. Jonas, do you have any dsymutil patches I can look at? I am interested in seeing what kind of interfaces are you using, particularly on the reading side. I think the current

On 2020-05-28, David Blaikie wrote: >On Thu, May 28, 2020 at 2:52 PM Robinson, Paul <paul.robinson at sony.com> >wrote: > >> As has been mentioned elsewhere, Sony generally fixes up references from >> debug info to stripped functions (of any length) using -1, because that’s a >> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base >>

The next feature on my DWARF 5 list is the line-table header. While this is pretty easy generate, it is a real bear to parse, so I thought I should let y'all know what I'm up to and why as I head out to the yak farm. Any thoughts and suggestions would be very much appreciated. The v5 directory and file tables no longer have a fixed format; instead, we have a list of field descriptors

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

On Fri, May 29, 2020 at 9:21 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: Fangrui Song <maskray at google.com> > > Sent: Friday, May 29, 2020 1:07 AM > > To: David Blaikie <dblaikie at gmail.com> > > Cc: Robinson, Paul <paul.robinson at sony.com>; Alexey Lapshin > >

Hi Pavel, As mentioned by Adrian in the comment you linked, I too am looking at DWARFv5 accelerator tables in LLVM. To give you some background: my motivation is that I want to upstream support for (Apple style) accelerator tables in llvm-dsymutil, which is currently missing because the way they are generated is slightly different. As this requires making changes the current code, I wanted to

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

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

> On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As mentioned by Adrian in the comment you linked, I too am looking at DWARFv5 > accelerator tables in LLVM. > > To give you some background: my motivation is that I want to upstream support > for (Apple style) accelerator tables in llvm-dsymutil, Some background for

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

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

> Subject: Re: [llvm-dev] Range lists, zero-length functions, linker gc > > On 2020-05-28, David Blaikie wrote: > >On Thu, May 28, 2020 at 2:52 PM Robinson, Paul <paul.robinson at sony.com> > >wrote: > > > >> As has been mentioned elsewhere, Sony generally fixes up references > from > >> debug info to stripped functions (of any length) using

What does gcc do? On Fri, Aug 24, 2018 at 9:05 AM via llvm-dev <llvm-dev at lists.llvm.org> wrote: > There are two forms of the .file directive. One is simply > > .file "path" > > and the other is > > .file <file-number> [ "dir"] "path" [ …. other stuff ] > > > > The latter is sometimes

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

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