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

[Eric Christopher]

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).

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

-eric