This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Feb 23, 2011 at 1:55 PM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> wrote:
>> Applied patch don't have those types any more. I introduced them in
>> initial patch under assumption structures in include/dwarf2.h should
>> be host-independent. As now those structures are moved into binutils
>> private header binutils/dwarf.h there is no need to have here new
>> types and patch uses bfd_vma/bfd_signed_vma.
>
> ?Whoops, my fault, indeed!
>
>> So what exactly is the point where you see here still the use of
>> dw2_vma_t/dw2_svma_t?
>
> ?Oh, sorry, you are right,
> I didn't realize that the new
> introduced type called 'dwarf_vma'
> was in fact introduced back to 2010 ...
> by a commit by H.J. Lu from 2010-11-21.
>
> ?So that my question in fact should have been sent to
> H.J. Lu, not to you.
>
> So let me re-ask the question to the right person:
>
>
> please excuse me for asking this so late,
> but I don't really understand why you had to introduce
> a new 'dwarf_vma' type when we already have a 'bfd_vma'
> type that must be unsigned 64-bit as soon as
> BFD64 macro is defined...
> See definitions in bfd/bfd-in.h or bfd/bfd-in2.h
>
> This macro should be set if any of the supported target is a 64-bit target
> so it should be possible to use that type, no?
>
> ?But of course, I might be missing some important point,
> could you please explain to me in which case
> a 64-bit dwarf_vma could be necessary without BFD64 being set.
> (I just realized in between that dwarf_vma is an unsigned type.)
>
> ?I still think that my question is valid,
> but I was unable to find the discussion about the
> patch in the mailing list which might contain
> an explanation.
>
> ?H.J., could you please give me a pointer
> to the thread where the patch is explained or
> comment on my question?

dwarf.h is also used by readelf.c, whose feature isn't
controlled by BFD64:

---
#if __GNUC__ >= 2
/* Define BFD64 here, even if our default architecture is 32 bit ELF
   as this will allow us to read in and parse 64bit and 32bit ELF files.
   Only do this if we believe that the compiler can support a 64 bit
   data type.  For now we only rely on GCC being able to do this.  */
#define BFD64
#endif

....
#include "dwarf.h"
---

dwarf_vma should be the same inside and outside of readelf.c.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]