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 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 else. Unfortunately > as the biggest consumer debugger testsuites have a tendency to be the > primary quality test for debug info.I have thought that a GDB bot would be a good idea, but then it would be a specific version of GDB, and opinions differ on what would be the "right" version. I suppose any version is better than nothing... 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! And you don't get to test the DWARF directly, you get to test how the debugger uses the DWARF. Not really optimal, but still--a whole lot better than nothing.> > Dwarf implementation in LLVM, as far as I know, is ad-hoc, so you'll > > have to do some refactoring (for good) on the debug emission code. > > I've tried to formally implement a few things, but in general it was > ad-hoc for so long this is true.Yeah, clearly some DWARF 3 bits are creeping in, and more will come. (I have some UTF-8 work waiting for a chance to be cleaned up and submitted, for example. DW_AT_use_UTF8 is a DWARF 3 attribute.) But if some people really are stuck in DWARF 2 land, we might have to do something intelligent about it. (I'd rather not, I'd rather have LLVM assert that DWARF 3 is where it's at. I mean really, DWARF 3 was published in 2005!) --paulr
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, have to sleep on that. This flag must go to the backend. Then the patch will change the conditional for DW_FORM_flag_present that caused the problem back to the old DW_FORM_flag when -gdwarf2 or 3 is set. In the future, there is a now a place to address compatibility issues that come up. ---- Monitoring this with GDB Testsuite as Jenkins or Buildbot would be a good idea. 20K+ tests are difficult to duplicate. GDB Testsuite is not easy to run and get stable, but I've been doing it for a few months now, and it can be done. One advantage with LLVM is that x86 will do a fair job covering the other architectures, and then a small number of tests to cover the gaps would be all that is needed. 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. Cheers, - rick -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Robinson, Paul Sent: Wednesday, October 17, 2012 8:53 PM To: Eric Christopher; Renato Golin Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] DWARF 2/3 backwards compatibility? 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 forus. 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 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 else. Unfortunately > as the biggest consumer debugger testsuites have a tendency to be the > primary quality test for debug info.I have thought that a GDB bot would be a good idea, but then it would be a specific version of GDB, and opinions differ on what would be the "right" version. I suppose any version is better than nothing... 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! And you don't get to test the DWARF directly, you get to test how the debugger uses the DWARF. Not really optimal, but still--a whole lot better than nothing.> > Dwarf implementation in LLVM, as far as I know, is ad-hoc, so you'll > > have to do some refactoring (for good) on the debug emission code. > > I've tried to formally implement a few things, but in general it was > ad-hoc for so long this is true.Yeah, clearly some DWARF 3 bits are creeping in, and more will come. (I have some UTF-8 work waiting for a chance to be cleaned up and submitted, for example. DW_AT_use_UTF8 is a DWARF 3 attribute.) But if some people really are stuck in DWARF 2 land, we might have to do something intelligent about it. (I'd rather not, I'd rather have LLVM assert that DWARF 3 is where it's at. I mean really, DWARF 3 was published in 2005!) --paulr _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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! And you don't get to test the DWARF > directly, you get to test how the debugger uses the DWARF. Not really > optimal, but still--a whole lot better than nothing.The trade off also goes in the other direction. If you had a strict Dwarf parser green, that would mean next to nothing as to what that Dwarf would represent in the debugger(s). AFAIK, most Dwarf compatible debuggers are also GDB compatible, which means that even the idiotic things that GDB does will probably be understood by other debuggers.> I mean really, DWARF 3 was published in 2005!)Go tell that to embedded folks and their certifications! ;) But yeah, focusing on Dwarf 3 would be the best way forward, adding a little bit for compatibility (rather than making Dwarf 2 a full-class citizen). -- cheers, --renato http://systemcall.org/
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, but hopefully, being actively monitored. Maybe would be good to add a directory (if there isn't one yet) to the testsuite repository, or at least the code necessary to make it run on LLVM. -- cheers, --renato http://systemcall.org/
On Thu, Oct 18, 2012 at 12:44 AM, Renato Golin <rengolin at systemcall.org> 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! And you don't get to test the DWARF >> directly, you get to test how the debugger uses the DWARF. Not really >> optimal, but still--a whole lot better than nothing. > > The trade off also goes in the other direction. If you had a strict > Dwarf parser green, that would mean next to nothing as to what that > Dwarf would represent in the debugger(s). > > AFAIK, most Dwarf compatible debuggers are also GDB compatible, which > means that even the idiotic things that GDB does will probably be > understood by other debuggers. >As long as we keep to standard dwarf I'm OK.> But yeah, focusing on Dwarf 3 would be the best way forward, adding a > little bit for compatibility (rather than making Dwarf 2 a full-class > citizen).Going to disagree here, the state of the art in debuggers isn't stopping back at dwarf 3 and we shouldn't either. I've already added some features from dwarf 4 into clang and will be adding dwarf 5 features as we work them through standardization. That said a flag to delineate dwarf versions is fine and we can work on making sure features don't bleed over. -eric
On Wed, Oct 17, 2012 at 9:11 PM, Rick Foos <rfoos at codeaurora.org> wrote:> 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. >Sounds good.> 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, have to sleep on that. This flag must go to the backend. >Yep. Sounds like what we were talking about yesterday. It'll need to be both in the front and back end because there are features used in the front end as well as encoding differences in the backend.> Then the patch will change the conditional for DW_FORM_flag_present that > caused the problem back to the old DW_FORM_flag when -gdwarf2 or 3 is set. >There are a few other bits that it should change as well, I'm guessing you haven't tried compiling too much c++11 code for your restricted dwarf set yet :) -eric
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! And you don't get to test the DWARF > > directly, you get to test how the debugger uses the DWARF. Not really > > optimal, but still--a whole lot better than nothing. > > The trade off also goes in the other direction. If you had a strict > Dwarf parser green, that would mean next to nothing as to what that > Dwarf would represent in the debugger(s).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. :-) Sure, the acid test is whether the debugger does the right thing. I'm not saying debugger-based tests are worthless, I'm saying that _just_ having debugger-based tests is not _optimal_. DWARF-level testing would let you do things that debugger-based tests would find anywhere from awkward to impossible. That said, what's easiest is probably to get some form of GDB bot up and running, and the benefit is likely to be worth the pain.> AFAIK, most Dwarf compatible debuggers are also GDB compatible, which > means that even the idiotic things that GDB does will probably be > understood by other debuggers.I don't think what GDB _does_ will be understood by other debuggers. :-) And the debugger for some of the platforms I have to deal with is certainly not GDB, so I care more about generating valid DWARF than I do about getting GDB running smoothly. I do recognize that the majority of LLVM targets care more about GDB, though. Cheers, --paulr