This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Update readelf to know about the new ELF constants
- To: nickc at redhat dot com
- Subject: Re: Update readelf to know about the new ELF constants
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Date: Mon, 27 Nov 2000 20:30:04 +0100
- CC: binutils at sources dot redhat dot com
> Date: Mon, 27 Nov 2000 11:12:51 -0800
> From: Nick Clifton <nickc@redhat.com>
> Looking through common.h, I think that we ought to try to register the
> following values:
> Hi Uli,
> : I''m not sure this will be OK. All the numbers allocates are in
> : sequence (with a few holes left).
>
> Is there a good reason for this ? These are just numbers right ?
>
> The values mentioned above are already in use in real code, so
> changing them would not be a good idea. Unless there is a real need
> to have consecutive EM_ values, I would prefer to leave them alone.
>
> : Besides, there is already a EM_ALPHA.
>
> Except that it is not used, at least not by the binutils code.
> Would you agree to calling it:
>
> #define EM_ALPHA_ALTERNATE 0x9026 /* An alternate DEC Alpha machine number. */
I might be pointing out the obvious (but it doesn't look like
it), please forgive:
In elf-bfd.h, struct elf_backend_data, you'll find
infrastructure to recognize (but not emit, methinks) legacy
(unregistered ad-hoc) e_machine values like the ones you listed:
/* Alternate EM_xxxx machine codes for this backend. */
int elf_machine_alt1;
int elf_machine_alt2;
Each entity or maintainer responsible for the machines with
unofficial e_machine numbers should ask registry@sco.com for an
officially blessed (in-sequence) number.
Perhaps you knew that. Now maybe more people know it.
brgds, H-P