similar to: [LLVMdev] DWARF 2/3 backwards compatibility?

> My GDB Testsuite runs have been failing more tests, and now an internal test > has started failing on some missing dwarf 3 records. What is the error message or the nature of the failures you are seeing ? Pranav Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

The error we are getting is: "Undefined Form Value: 25" We have customers that have a variety of debuggers, and we need to be able to preserve Dwarf3 compatibility. GDB, Lauterbach, etc. The patch that caused a problem for us is: https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp?r1=162493&r2=162526&pathrev=162526&diff_format=h

I'd like to summarize what we've discussed for a moment, and propose a patch tomorrow. It will clear a problem we have, and provide a way to handle a lot more of these that will come up as we go to Dwarf 5, and the next GDB. The framework is a set of GCC like gdwarf[2,3,4,5] flags. I can see cases where compatibility is 2,3 or 2,3,4, so maybe the flag is a number to allow <=3 tests,

Rick Foos wrote: > The error we are getting is: > “Undefined Form Value: 25” > ... > DW_FORM_flag_present caused the problem. The old DW_FORM_flag works for us. I see this error from GDB 7.0 but GDB 7.2 is okay with it. Now you know as much as I do. :-) Eric Christopher wrote: > [in reply to what Renato Golin wrote:] > > With time, you might get to a point where Dwarf is a

> With time, you might get to a point where Dwarf is a first-class > citizen and there will be basic compatibility checks in "make check" > and a build bot for GDB test suite on some platforms, but to get > there, you'll go through a lot of pain. > Hopefully not too much. Paul has been helping and I add tests whenever I fix something, but a quality suite is something

On 17 October 2012 21:09, Eric Christopher <echristo at gmail.com> wrote: >> 1) What level of interest is there in Dwarf backward compatibility; > > I don't have a lot of interest in keeping dwarf backward compatibility > past my ability to test things, hence the option for darwin's gdb. Very few people have, and Dwarf is not an easy target, so the cost of having a

Hi, I have a newbie question regarding debugging support in llvm. Is llvm generating DWARF2 or DWARF3? The comments in the trunk source code refer to the DWARF 3 spec, but DWARF_VERSION is set to 2 in Support/Dwarf.h. What am I missing? Thanks. -- Yuan ----------------------------------------------------------------------------------- This email message is for the sole use of the intended

On 10/18/2012 01:39 PM, David Blaikie wrote: > On Thu, Oct 18, 2012 at 11:19 AM, Rick Foos<rfoos at codeaurora.org> wrote: >> On 10/18/2012 10:36 AM, David Blaikie wrote: >>> On Thu, Oct 18, 2012 at 12:48 AM, Renato Golin<rengolin at systemcall.org> >>> wrote: >>>> On 18 October 2012 05:11, Rick Foos<rfoos at codeaurora.org> wrote:

On 18 October 2012 21:36, Robinson, Paul <Paul.Robinson at am.sony.com> wrote: > Well, having IR-level testing tells you next to nothing as to what your > program would actually do when you compile and run it. But it seems > to me that we have a huge pile of IR-level tests, so _somebody_ must > think they are useful. :-) When creating Dwarf tests I did it at all levels: IR

On 18 October 2012 05:11, Rick Foos <rfoos at codeaurora.org> wrote: > I don't think GDB testsuite should block a commit, it can vary by a few > tests, they rarely if ever all pass 100%. Tracking the results over time can > catch big regressions, as well as the ones that slowly increase the failed > tests. Agreed. It should at least serve as comparison between two branches,

> > Take the log file, check out the suite, rerun a failing test, use dwarfdump > and llvm-dwarfdump, find the "bad" dwarf records produced by the compiler. > > All the eventual bugs are about dwarf records, and a gdb testsuite test to > duplicate. > That's not necessarily the case. > A bad/confused dwarf record fails multiple tests without a way to map a

On Thu, Oct 18, 2012 at 12:48 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 18 October 2012 05:11, Rick Foos <rfoos at codeaurora.org> wrote: >> I don't think GDB testsuite should block a commit, it can vary by a few >> tests, they rarely if ever all pass 100%. Tracking the results over time can >> catch big regressions, as well as the ones that

Hi All, I just enabled the generation of dwarf debugging information for Hexagon. It did not require much save for the setting of a flag in MCAsmInfo. However, now I see that the ".debug_pubnames" sections is not generated. I did read discussion about the section not really being useful for debuggers in terms of accelerated access, but I have code that uses libdwarf to check for global

I'm trying to write a llvm pass to add debug info into a non-debug-info bitcode file. I have been read http://llvm.org/docs/SourceLevelDebugging.html. And I use DIBuilder to produce the debug metadata. I know I can't get all information form ir code . So I add some manual info as test data. After executing my pass, I can find debug info metadata in my generated bitcode. Those metadata

Renato Golin wrote: > On 18 October 2012 02:53, Robinson, Paul <Paul.Robinson at am.sony.com> wrote: > > I had a "quality suite" at a previous job; it was the result of many PY > > of effort. It was also debugger-based, which is a mixed blessing; you > > get a lot of DWARF-parsing code for free, but then you get a lot of > > debugger bugs for free too!

On Thu, Oct 18, 2012 at 11:19 AM, Rick Foos <rfoos at codeaurora.org> wrote: > On 10/18/2012 10:36 AM, David Blaikie wrote: >> >> On Thu, Oct 18, 2012 at 12:48 AM, Renato Golin<rengolin at systemcall.org> >> wrote: >>> >>> On 18 October 2012 05:11, Rick Foos<rfoos at codeaurora.org> wrote: >>>> >>>> I don't think

On 10/18/2012 10:36 AM, David Blaikie wrote: > On Thu, Oct 18, 2012 at 12:48 AM, Renato Golin<rengolin at systemcall.org> wrote: >> On 18 October 2012 05:11, Rick Foos<rfoos at codeaurora.org> wrote: >>> I don't think GDB testsuite should block a commit, it can vary by a few >>> tests, they rarely if ever all pass 100%. Tracking the results over time

On 10/18/2012 04:23 PM, Eric Christopher wrote: >> Take the log file, check out the suite, rerun a failing test, use dwarfdump >> and llvm-dwarfdump, find the "bad" dwarf records produced by the compiler. >> >> All the eventual bugs are about dwarf records, and a gdb testsuite test to >> duplicate. >> > That's not necessarily the case. >

On Mar 8, 2012, at 2:29 PM, Pranav Bhandarkar wrote: > Hi All, > > I just enabled the generation of dwarf debugging information for Hexagon. It > did not require much save for the setting of a flag in MCAsmInfo. > > However, now I see that the ".debug_pubnames" sections is not generated. I > did read discussion about the section not really being useful for

Hi Eric, > Nope, it's removed completely. No debugger that I know of uses it at > all and it's > useless for many reasons. Adding the code back in to generate it is > possible (it's > a fairly small commit that's easily reverted), but I see no reason to > have it generated > by default. What are you doing that involves looking for global > variables in the