public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
Cc: Kai Tietz <ktietz70@googlemail.com>, Binutils <binutils@sourceware.org>
Subject: Re: [RFC patch]: Adjust the use of 'long' type in dwarf2.h header
Date: Wed, 23 Feb 2011 22:51:00 -0000	[thread overview]
Message-ID: <AANLkTimZ59JPpUSmqEaGGdT6c=pb+5mLQ1giCz8o=JB0@mail.gmail.com> (raw)
In-Reply-To: <-3886800211494155692@unknownmsgid>

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.

  parent reply	other threads:[~2011-02-23 22:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-17 14:21 Kai Tietz
2011-02-17 18:59 ` Kai Tietz
2011-02-17 19:03   ` Jakub Jelinek
2011-02-17 19:07     ` Kai Tietz
2011-02-17 19:17       ` Jakub Jelinek
2011-02-18  9:50         ` Kai Tietz
2011-02-21 12:37           ` NightStrike
2011-02-21 13:10 ` Pierre Muller
     [not found] ` <-8460070221060995487@unknownmsgid>
2011-02-21 13:27   ` Kai Tietz
2011-02-21 13:46     ` Pierre Muller
     [not found]     ` <-6930711422310680743@unknownmsgid>
2011-02-21 14:30       ` Kai Tietz
2011-02-21 15:25         ` Kai Tietz
2011-02-21 15:43           ` Mark Kettenis
2011-02-21 15:53             ` Kai Tietz
2011-02-22 15:21           ` Nick Clifton
2011-02-23  8:59             ` Kai Tietz
2011-02-23 15:12               ` Pierre Muller
     [not found]               ` <-2339605939192327273@unknownmsgid>
2011-02-23 17:42                 ` Kai Tietz
2011-02-23 21:55                   ` Pierre Muller
     [not found]                   ` <-3886800211494155692@unknownmsgid>
2011-02-23 22:51                     ` H.J. Lu [this message]
2011-02-24 11:33                       ` Pierre Muller
     [not found]                       ` <1561346207520594884@unknownmsgid>
2011-02-24 13:50                         ` H.J. Lu
2011-02-25 10:40                           ` [RFC] Use only dwarf_vma types in dwarf code (was RE: [RFC patch]: Adjust the use of 'long' type in dwarf2.h header) Pierre Muller
     [not found]                           ` <5095785081977025060@unknownmsgid>
2011-02-25 12:23                             ` Kai Tietz
2011-02-25 13:31                               ` Pierre Muller
2011-02-25 13:35                               ` [RFC-v2] Use only dwarf_vma types in dwarf code Pierre Muller
2011-03-25 15:16                                 ` Nick Clifton
2011-03-25 15:48                                   ` [RFA] Supplemtal patch for use " Pierre Muller
2011-03-25 18:04                                     ` Nick Clifton
2011-03-25 21:44                                       ` Pierre Muller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTimZ59JPpUSmqEaGGdT6c=pb+5mLQ1giCz8o=JB0@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=ktietz70@googlemail.com \
    --cc=pierre.muller@ics-cnrs.unistra.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).