similar to: [LLVMdev] RFC: Improving our DWARF (and ELF) emission testing capabilities

On Fri, Jan 18, 2013 at 1:00 PM, Eli Bendersky <eliben at google.com> wrote: > Hi All, > > While working on some recent patches for x32 support, I ran into an > unpleasant limitation the LLVM eco-system has with testing DWARF > emission. We currently have several approaches, neither of which is > great: > > 1. llvm-dwarfdump: the best approach when it works. But

+ other debug info people (Eric & Paul) On Fri, Jan 18, 2013 at 1:00 PM, Eli Bendersky <eliben at google.com> wrote: > Hi All, > > While working on some recent patches for x32 support, I ran into an > unpleasant limitation the LLVM eco-system has with testing DWARF > emission. We currently have several approaches, neither of which is > great: > > 1.

On Fri, Jan 18, 2013 at 4:00 PM, Eli Bendersky <eliben at google.com> wrote: > Hi All, > > While working on some recent patches for x32 support, I ran into an > unpleasant limitation the LLVM eco-system has with testing DWARF > emission. We currently have several approaches, neither of which is > great: > > 1. llvm-dwarfdump: the best approach when it works. But

>> 1. llvm-dwarfdump: the best approach when it works. But unfortunately >> lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections >> like debug_frame aren't supported. > > Ideally I'd like to see support added whenever a code change is made > to a feature - so long as we hold ourselves to a "test new changes" > that can

>> 1. llvm-dwarfdump: the best approach when it works. But unfortunately >> lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections >> like debug_frame aren't supported. >> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >> cumbersome and misses a lot of things like actual DWARF encoding. >> 3. Using elf-dump and examining

On Tue, Jan 22, 2013 at 3:35 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > On Fri, Jan 18, 2013 at 4:00 PM, Eli Bendersky <eliben at google.com> wrote: >> Hi All, >> >> While working on some recent patches for x32 support, I ran into an >> unpleasant limitation the LLVM eco-system has with testing DWARF >> emission. We currently have several

On Feb 11, 2013, at 18:13, Eli Bendersky <eliben at google.com> wrote: > On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: >> Hi, >> >> I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory

Hi, I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish

On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: > Hi, > > I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is

>> > I'm fine with this as long as llvm-dwarfdump gets maintained. >> > >> >> I agree, and as I said in the original email, in the long term I >> believe llvm-dwarfdump is the correct solution. >> > > The problem is that if no one is working on testing these sorts of things > with llvm-dwarfdump then it won't be maintained for this

On Fri, Jan 18, 2013 at 3:13 PM, Eli Bendersky <eliben at google.com> wrote: > >> > I'm fine with this as long as llvm-dwarfdump gets maintained. > >> > > >> > >> I agree, and as I said in the original email, in the long term I > >> believe llvm-dwarfdump is the correct solution. > >> > > > > The problem is that if

On Tue, Jan 22, 2013 at 3:23 PM, Robinson, Paul <Paul.Robinson at am.sony.com> wrote: >>>> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >>>> cumbersome and misses a lot of things like actual DWARF encoding. >>> >>> I'm not sure what you mean by "actual DWARF encoding" here. >>> (disclaimer: I've only

Nick, Do you happen to know why the version reported in 'dwarfdump --eh-frame' for object files now differs when compiled with and without -g? The test used in FSF gcc's configure produces a diff of.. % diff -u conftest.o.g.stripped.dwarfdump conftest.o.g0.stripped.dwarfdump --- conftest.o.g.stripped.dwarfdump 2015-04-10 21:43:15.000000000 -0400 +++

>>> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >>> cumbersome and misses a lot of things like actual DWARF encoding. >> >> I'm not sure what you mean by "actual DWARF encoding" here. >> (disclaimer: I've only recently started dabbling with debug info, so I >> may be missing obvious things) > > I mean that it

On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Nagaraju > > Mekala via llvm-dev > > Sent: Tuesday, April 21, 2020 6:04 AM > > To: jh7370.2008 at my.bristol.ac.uk > > Cc: LLVM Developers Mailing List

On Wed, Apr 22, 2020 at 10:34 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Apr 22, 2020 at 9:28 AM Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: >> > >> > >> > >> > > -----Original Message-----

David Blaikie [dblaikie at gmail.com] wrote: > On Tue, Jan 22, 2013 at 3:23 PM, Robinson, Paul > <Paul.Robinson at am.sony.com> wrote: >>>>> 2. Relying of assembly directive emissions (i.e. .cfi_*), which is >>>>> cumbersome and misses a lot of things like actual DWARF encoding. >>>> >>>> I'm not sure what you mean by

On 01 Sep 2010, at 08:47, Talin wrote: > Once again, I have no idea what this means or how to go about > debugging it. > This is my biggest frustration with DIFactory - there's absolutely > no way to > verify that the DWARF debugging information that I've emitted into > my module > is correct or even sensible. The only way to test it is to try and > debug

On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > > On 01 Sep 2010, at 08:47, Talin wrote: > > > Once again, I have no idea what this means or how to go about > > debugging it. > > This is my biggest frustration with DIFactory - there's absolutely > > no way to > > verify that the DWARF debugging information that

There should be a line-table entry for the end of the function, which appears to be missing from the dump you provided. llvm-dwarfdump should report this address with 'end_sequence' in the Flags. Are you using a different dumper? I am not sure but my guess would be that inline data is not represented in the line table. The line table's primary purpose is to inform the debugger