This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]