<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Apr 4, 2013, at 10:47 AM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">On Thu, Apr 4, 2013 at 10:21 AM, Manman Ren <<a href="mailto:mren@apple.com">mren@apple.com</a>> wrote:<br><blockquote type="cite"><br>On Apr 3, 2013, at 6:59 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br><br>Debug Info: according to DWARF 2, FORM_ref_addr the same size as an address<br>on<br>the target system.<br><br>It was hard-coded to 4 bytes before. I can't get llvm to generate a<br>ref_addr on a reasonably sized testing case.<br><br><a href="rdar://problem/13559431">rdar://problem/13559431</a><br><br><br>Unfortunately our current version really isn't 2, there are many<br>dwarf4-isms in our current output. If you'd like to have a dwarf-2<br>compatibility mode then you'll need to submit a patch that delineates<br>that through all of compilation.<br><br><br>The DWARF_VERSION is set to 2 in llvm/Support/Dwarf.h so the header of our<br>object file will say version 2.<br>Also our llvm dwarf parser does not check DWARF version and will parse<br>ref_addr according to version 2.<br>And here it seems that we only support version 2 and 3.<br> static bool isSupportedVersion(unsigned version) {<br> return version == 2 || version == 3;<br> }<br><br></blockquote><br>Seems easy to fix here. :)<br><br><blockquote type="cite">I know there are supports of dwarf4 stuff in our current debug info.<br>Are you okay with me changing the DWARF_VERSION to 4?<br>It may break a lot of things.<br></blockquote><br>Really it just needs to be 3+ for the pointer size versus<br>DWARF32/DWARF64 for 4/8, but I'm fine with this change. It should be<br>tested and any bugs fixed though.<br><br><blockquote type="cite">Another way is to enable this change only for darwin gdb.<br><br></blockquote><br>No. This is also a bad idea. If we want dwarf2 compatibility then we<br>should plumb it through the front end and backend appropriately. Up<br>until now we've been working off of the dwarf4 standard for everything<br>standardized and having feature compatibility sets when that's not<br>applicable. This is, unfortunately enough, a change in the data layout<br>of dwarf between revisions and would be best handled by being able to<br>separate out dwarf handling by major version and then have feature<br>sets we can apply on top of it (like the accelerator tables or fission<br>that are proposals for dwarf5).<br></div></blockquote>Hi Eric,</div><div><br></div><div>After talking with Greg, we have to stick with dwarf2 format of ref_addr</div><div>since our tool chains can only handle that right now. Similar to what we have for llvm-dwarfdump,</div><div>our tool chains are in the process of migrating to Dwarf4, we handle some Dwarf4 features and may</div><div>deviate from Dwarf4 when there are incompatibilities.</div><div><br></div><div>We don't really want dwarf2 compatibility. If you think it is wrong to use DarwinGDBCompat, do you have any suggestion?</div><div><br></div><div>Thanks,</div><div>Manman</div><div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><br>FWIW I think a reasonable test case for this would be a small merged<br>set of compile units that reference each other.<br><br>-eric</div></blockquote></div><br></body></html>