[llvm] r178722 - Debug Info: according to DWARF 2, FORM_ref_addr the same size as an address on

[Manman Ren]

On Apr 4, 2013, at 10:47 AM, Eric Christopher <echristo at gmail.com> wrote:

> On Thu, Apr 4, 2013 at 10:21 AM, Manman Ren <mren at apple.com> wrote:
>> 
>> On Apr 3, 2013, at 6:59 PM, Eric Christopher <echristo at gmail.com> wrote:
>> 
>> Debug Info: according to DWARF 2, FORM_ref_addr the same size as an address
>> on
>> the target system.
>> 
>> It was hard-coded to 4 bytes before. I can't get llvm to generate a
>> ref_addr on a reasonably sized testing case.
>> 
>> rdar://problem/13559431
>> 
>> 
>> Unfortunately our current version really isn't 2, there are many
>> dwarf4-isms in our current output. If you'd like to have a dwarf-2
>> compatibility mode then you'll need to submit a patch that delineates
>> that through all of compilation.
>> 
>> 
>> The DWARF_VERSION is set to 2 in llvm/Support/Dwarf.h so the header of our
>> object file will say version 2.
>> Also our llvm dwarf parser does not check DWARF version and will parse
>> ref_addr according to version 2.
>> And here it seems that we only support version 2 and 3.
>>  static bool isSupportedVersion(unsigned version) {
>>    return version == 2 || version == 3;
>>  }
>> 
> 
> Seems easy to fix here. :)
> 
>> I know there are supports of dwarf4 stuff in our current debug info.
>> Are you okay with me changing the DWARF_VERSION to 4?
>> It may break a lot of things.
> 
> Really it just needs to be 3+ for the pointer size versus
> DWARF32/DWARF64 for 4/8, but I'm fine with this change. It should be
> tested and any bugs fixed though.
> 
>> Another way is to enable this change only for darwin gdb.
>> 
> 
> No. This is also a bad idea. If we want dwarf2 compatibility then we
> should plumb it through the front end and backend appropriately. Up
> until now we've been working off of the dwarf4 standard for everything
> standardized and having feature compatibility sets when that's not
> applicable. This is, unfortunately enough, a change in the data layout
> of dwarf between revisions and would be best handled by being able to
> separate out dwarf handling by major version and then have feature
> sets we can apply on top of it (like the accelerator tables or fission
> that are proposals for dwarf5).
Hi Eric,

After talking with Greg, we have to stick with dwarf2 format of ref_addr
since our tool chains can only handle that right now. Similar to what we have for llvm-dwarfdump,
our tool chains are in the process of migrating to Dwarf4, we handle some Dwarf4 features and may
deviate from Dwarf4 when there are incompatibilities.

We don't really want dwarf2 compatibility. If you think it is wrong to use DarwinGDBCompat, do you have any suggestion?

Thanks,
Manman

> 
> FWIW I think a reasonable test case for this would be a small merged
> set of compile units that reference each other.
> 
> -eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130404/1e62015c/attachment.html>