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 DW_FORM_flag_present caused the problem. The old DW_FORM_flag works for us. While the DD->useDarwinGDBCompat() option is a workaround in this case, Darwin GDB is a specific version of GDB. http://sourceware.org/gdb/onlinedocs/gdb/Darwin.html So useDarwinGDBCompat means Darwin GDB Compatibility, not GDB Compatibility or Dwarf xxx Compatibility, etc. Going in that direction for now means that we will hit this problem again. Eventually useDarwinGDBCompat should diverge to things that don't apply to all GDB's. Would like to discuss: 1) What level of interest is there in Dwarf backward compatibility; 2) What levels of Debugger backward compatibility are needed. 3) What framework of flags/options would be a container for specific backward compatibility features. 4) What type of testing to ensure backward compatibility, GDB Testsuite? Thank you! -rick On 10/17/2012 10:53 AM, Pranav Bhandarkar wrote:> >> 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 > > >-- Rick Foos Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121017/62c3a993/attachment.html>
> Would like to discuss: > 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. That said if people want to have more strict options I can easily keep the dwarf stuff I'm working on inside of that framework.> 2) What levels of Debugger backward compatibility are needed.Probably "old gdb" which for a lot of our platforms is pretty much the darwin gdb. If we absolutely need to we can wall things off based on dwarf version, but that's a bit of a pain. At that point I'd probably want to throw something into either that compile unit metadata or the module itself on what level of dwarf I can use. Bill's work on module level attributes would probably come in a little handy here.> 3) What framework of flags/options would be a container for specific > backward compatibility features.DWARF version is probably the easiest for now. If we ever hit the point of emitting another form of debug info we can worry about that.> 4) What type of testing to ensure backward compatibility, GDB Testsuite?This is key, if there's no way I can test that I haven't broken a platform (or at the least something yelling at me that I have broken a platform) then there's not much I can do about it. -eric
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 fully compatible Dwarf (2 and 3) is not low. Also, as Eric mentions, the GDB test suite is not the most gracious thing to setup and keep tidy for the many platforms LLVM supports. 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. And I don't think you'll be able to recruit too many people for that crusade, either... ;) 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. Eric, What about the LLDB, does it support Dwarf? Is it good enough for C *and* C++? -- cheers, --renato http://systemcall.org/