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

["Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>]

> 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?

  Thanks in advance,


Pierre Muller
GDB pascal language maintainer