Re: [RFC patch]: Adjust the use of 'long' type in dwarf2.h header

[Kai Tietz <ktietz70@googlemail.com>]

2011/2/17 Jakub Jelinek <jakub@redhat.com>:
> On Thu, Feb 17, 2011 at 07:58:56PM +0100, Kai Tietz wrote:
>> 2011/2/17 Kai Tietz <ktietz70@googlemail.com>:
>> > This patch addresses issues I've seen in binutils about
>> > cross-compilers and dwarf2 display via objdump -W on hosts, which have
>> > sizeof (long) < target's sizeof(void *). Additionally same issue of
>> > course can be seen on LLP64 targets, too.
>> > Those issues are caused by the fact that the dwarf2.h header in
>> > include/ is using unconditionally the type 'unsigned long' for
>> > vma-scalars.
>> >
>> > This patch address additionally the binutils' dwarf.(c|h) files and
>> > make them host bitness independent for gcc base toolchains supporting
>> > the 'long long' type.
>> >
>> > I've tested the attached patches for gdb, binutils, and gcc on
>> > i686-w64-mingw32, and x86_64-w64-mingw32 cross-toolchains hosted on
>> > cygwin. And I didn't found until now regressions. Later this day I
>> > want to do a regression test for linux64, too.
>
> I'd prefer if we could move those binutils specific internal implementation
> details out of the dwarf2.h header, keep it really just for the stuff
> defined in the standard, and add a new binutils specific header somewhere
> else which would contain binutils specific details.
>
>        Jakub

Well, so we make dwarf2.h in include just host-specific and isn't able
to cover things for foreign target, like 32-bit host can't use this
header for 64-bit dwarf2 information. I am fine by this, but
nevertheless is then the use of 'unsigned long' type within this
header still an issue. Here should be used instead then 'intptr_t'. As
on LLP64 unsigned long isn't wide-enough.

Regards,
Kai