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

Eric Christopher echristo at gmail.com
Thu Apr 4 13:01:42 PDT 2013


On Thu, Apr 4, 2013 at 12:28 PM, Manman Ren <mren at apple.com> wrote:
>
> On Apr 4, 2013, at 12:19 PM, Eric Christopher <echristo at gmail.com> wrote:
>
> 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.
>
>
> Oddly enough we've been using the dwarf4 definition the entire timeā€¦
>
> Should we change our version in the CU header from 2 to 4 then?
>

Sure, though you'll need to watch bots and make sure nothing regresses.

>
>
> We don't really want dwarf2 compatibility. If you think it is wrong to use
> DarwinGDBCompat, do you have any suggestion?
>
>
> I don't know what else to tell you. This is a change to how dwarf
> worked between dwarf2 and dwarf3. If you need to enable some
> compatibility this belongs in a switch between dwarf2 and dwarf3 plus.
> The darwin gdb compatibility level can be used to set dwarf2 by
> default for darwin if you'd like, but ultimately the right way to fix
> this is to start delineating between dwarf 2 and dwarf3+. There just
> aren't any good 10-20 line solutions.
>
>
> I will enable this for DarwinGDBCompat, once our tool chains start working
> with
> the Dwarf3+ format of ref_addr, I will revert this change. Is that okay with
> you?
>

Not really, no, as I said above. Also the way you have the patch
currently has it hard coded for dwarf2 support and doesn't
conditionalize based on dwarf version. We need it to be based on dwarf
version (and theoretically dwarf32 versus dwarf64, but we don't even
vaguely claim to support dwarf64 at the moment) and then you can use
DarwinGDBCompat to set it to dwarf2.

-eric




More information about the llvm-commits mailing list