This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] Add sh4-nommu-nofpu architecture
- From: amylaar at spamcop dot net (Joern Rennecke)
- To: aoliva at redhat dot com (Alexandre Oliva)
- Cc: joern dot rennecke at superh dot com (Joern Rennecke), andrew dot stubbs at superh dot com (Andrew Stubbs), binutils at sources dot redhat dot com
- Date: Wed, 10 Mar 2004 00:29:02 +0000 (GMT)
- Subject: Re: [PATCH] Add sh4-nommu-nofpu architecture
> Oh, BTW, we've used number 7 too.
>
> > ! #define EF_SH4_NOMMU_NOFPU 7
>
> This number is a bad idea. Existing tools will take it as a DSP
> machine, because of the macro you removed, and report a very confusing
> error message.
No problem, I had picked that number only because it appeared to be the first
free one and I wanted to keep the table small. we can use 0x12 or some higher
number instead.
> Also, your code seems to assume there will always be a machine number
> that represents a superset of a given collection of machine numbers,
> except for DSP/FPU conflicts, but this is not true. SH5 is currently
> the only oddball, but there may be others. Ideally, there should be a
I think we actually use a different emulation for SH5, so it doesn't really
belong in the same number space.
> way to express `no match' in the table, and have an error be reported,
> instead of picking an incorrect match. We used to return -1 from the
> merge macro in such cases before; now there's nothing we can do
> AFAICT.
Where did we use to return -1?
We can return -1 for a nun-match simply by initializing best with -1.
Oops, I see now that the code that I posted is not quite the one I
meant to write:
! elf_elfheader (obfd)->e_flags = i;
This should be:
elf_elfheader (obfd)->e_flags = best;
> Frankly, I'd much rather have a static inline function with all the
> code needed to merge two machine numbers than this table that I don't
> find particularly appealing, especially with the additional corner
> cases handled in sh_elf_merge_private_data. Ideally, the merge
> function should be used for other purposes, not only in BFD.
I'm not aware that we need this code anywhere else. I had put
the merge macro in the headerfile before only because it was so
tightly coupled with the numberical values chosen.
Having the code in a into a proper .c file makes debugging much
easier. If we really need it somewhere else, we can still move it
to the header file.