All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@suse.de>
To: Emmanuel Ackaouy <ack@xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [patch 1/5] add libelf: an ELF binary parser library.
Date: Wed, 24 Jan 2007 09:34:02 +0100	[thread overview]
Message-ID: <45B719FA.8090409@suse.de> (raw)
In-Reply-To: <425431495d656c4e48ec8110b7dd80b7@xensource.com>

Emmanuel Ackaouy wrote:
> Hi Gerd,
> 
> I have to say I'm not a big fan of sticking a 32bit and 64bit version
> of each structure in a union and then checking at all levels of the
> function call stack which one to reference (via elf_xval() for example).
> 
> Wouldn't it be cleaner to just have 2 different version of each elf
> data structure and function? elf32_xxx and elf64_xxx . And go down
> one path or the other at the start of your function call stack?

No.

> I'm not
> usually a fan of multiple compilation, but due to the layout of 32
> and 64bit elf structures, this is one case where it makes sense
> to me.

It doesn't.  I did it both ways.  Not compiling twice is better.

It is much more flexible and makes reusing the code much easier.  You
can simply add your own functions without hassle.

Look at the libelf-use-readnotes.diff patch and the print_numeric_note()
function it adds to readnotes.c as an simple example.  How do you do
that when compiling twice?  Your options are:

 (1) push that into the library which is compiled twice anyway.
 (2) split it out into a separate source which you can compile twice.
 (3) write two versions of the function, one for 32 and one for 64 bit.

None of these options looks good to me.

> Also, do we actually have a need to look at elf files with a different
> ELFDATA (byte ordering) ?

Yes.  I think it is very handy if readnotes works on ppc kernels too.
Also some IA64 guys seem to work on mixed-endian support (there where
some messages on the list some weeks ago), for this it is required too.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

  reply	other threads:[~2007-01-24  8:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-23 14:53 [patch 0/5] libelf: new elf parser for xen Gerd Hoffmann
2007-01-23 14:53 ` [patch 1/5] add libelf: an ELF binary parser library Gerd Hoffmann
2007-01-23 15:27   ` Christoph Egger
2007-01-23 19:03   ` Emmanuel Ackaouy
2007-01-24  8:34     ` Gerd Hoffmann [this message]
2007-01-23 14:53 ` [patch 2/5] libelf: use for x86 dom0 builder Gerd Hoffmann
2007-01-23 19:10   ` Emmanuel Ackaouy
2007-01-24  8:41     ` Gerd Hoffmann
2007-01-24 21:00       ` Emmanuel Ackaouy
2007-01-25  7:59         ` Gerd Hoffmann
2007-01-23 14:53 ` [patch 3/5] libelf: add to libxc Gerd Hoffmann
2007-01-23 14:53 ` [patch 4/5] libelf: use for hvm builder Gerd Hoffmann
2007-01-23 14:53 ` [patch 5/5] libelf: use for readnotes utility Gerd Hoffmann

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=45B719FA.8090409@suse.de \
    --to=kraxel@suse.de \
    --cc=ack@xensource.com \
    --cc=xen-devel@lists.xensource.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.