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


Alexandre Oliva wrote:
> I'm thinking that there will be other cases in which there won't be a
> proper superset.  Unfortunately, I cannot disclose details of SH2A,
> but it won't fit in the framework you've created, because the
> numerical order you've assumed as possible is not possible.  As
> Renesas and SuperH design their new chips, I'm sure more such parts
> will come through.  We'll probably be better off with up_compat bits
> akin to the _up macros in the assembler.

Surely both the table in opcodes/sh-opc.h and the table in
include/elf/sh.h should describe exactly the same thing. I mean, the
linker is trying to decide which is the most generic instruction
set/architecture in exactly the same way as the linker. It does it based
on a series of files rather than a series of opcodes, but what else is
different?

That being the case, wouldn't it be better to unify them?  As I see it,
the only reason it was done differently in sh.h is that there was an
easier way to do it (based on the value of the magic number). Since that
technique is now invalid, and there doesn't seem to be any way to fix
it, is there any reason not to glue the two together? 'opcodes' and
'include' are always distributed together are they not?

I'm not sure where it might live exactly but here's a quick mock-up:

#define arch_sh1     0x0001
#define arch_sh2     0x0002
#define arch_sh3     0x0004
#define arch_sh3e    0x0008
#define arch_sh4     0x0010
#define arch_sh2e    0x0020
#define arch_sh4a    0x0040
#define arch_sh_dsp  0x0100
#define arch_sh3_dsp 0x0200
#define arch_sh4al_dsp 0x0400
#define arch_sh4_nofpu 0x1000
#define arch_sh4a_nofpu 0x2000
#define arch_sh4_nommu_nofpu 0x4000  /* no mmu nor fpu */

#define arch_sh1_up  (arch_sh1 | arch_sh2_up)
#define arch_sh2_up  (arch_sh2 | arch_sh2e_up | arch_sh3_up |
arch_sh_dsp)
#define arch_sh2e_up (arch_sh2e | arch_sh3e_up)
#define arch_sh3_up  (arch_sh3 | arch_sh3e_up | arch_sh3_dsp_up \
                      | arch_sh4_nommu_nofpu_up)
#define arch_sh3e_up (arch_sh3e | arch_sh4_up)
#define arch_sh4_up  (arch_sh4 | arch_sh4a_up)
#define arch_sh4a_up (arch_sh4a)

#define arch_sh_dsp_up (arch_sh_dsp | arch_sh3_dsp_up)
#define arch_sh3_dsp_up (arch_sh3_dsp | arch_sh4al_dsp_up)
#define arch_sh4al_dsp_up (arch_sh4al_dsp)

#define arch_sh4_nommu_nofpu_up (arch_sh4_nommu_nofpu |
arch_sh4_nofp_up)

#define arch_sh4_nofp_up (arch_sh4_nofpu | arch_sh4_up |
arch_sh4a_nofp_up)
#define arch_sh4a_nofp_up (arch_sh4a_nofpu | arch_sh4a_up |
arch_sh4al_dsp_up)

#define arch_sh_any_with_mmu (arch_sh3 | arch_sh3e_up | arch_sh3_dsp_up
\
        | arch_sh4_nofp_up)  /* arch _sh3_up omitting
arch_sh4_nommu_nofpu */

#define ARCH_HAS_DSP(a) (((a) & arch_sh_dsp_up) != 0)
#define ARCH_HAS_FPU(a) (((a) & arch_sh2e_up) != 0)

#define EF_SH_TABLE \
/* EF_SH_UNKNOWN	*/ arch_sh3_up		, \
/* EF_SH1		*/ arch_sh1_up		, \
/* EF_SH2		*/ arch_sh2_up		, \
/* EF_SH3		*/ arch_sh3_up		, \
/* EF_SH_DSP		*/ arch_sh_dsp_up	, \
/* EF_SH3_DSP		*/ arch_sh3_dsp_up	, \
/* EF_SHAL_DSP		*/ arch_sh4al_dsp_up	, \
/* 7			*/ 0, \
/* EF_SH3E		*/ arch_sh3e_up		, \
/* EF_SH4		*/ arch_sh4_up		, \
/* EF_SH5		*/ 0, \
/* EF_SH2E		*/ arch_sh2e_up		, \
/* EF_SH4A		*/ arch_sh4a_up		, \
/* 13, 14, 15		*/ 0, 0, 0, \
/* EF_SH4_NOFPU		*/ arch_sh4_nofp_up	, \
/* EF_SH4A_NOFPU	*/ arch_sh4a_nofp_up	, \
/* EF_SH4_NOMMU_NOFPU	*/ arch_sh4_nommu_nofpu_up

The linker could then operate a 'valid_arch' mechanism in the same way
the assembler does.
I'm sure the example contains flaws and all the names would probably
want altering but it demonstrates what I mean.

The issue of how the linker chooses the architecture also has a
significance to something else I have been thinking over. With all these
new (and old) variants sprouting all over the place it is becoming
increasingly important that users are certain what architecture an
executable is aimed at. I.e. If I am working on a binary for the SH-4
500 series CPU (an fpu-less SH-4) I would like to be able to instruct
the toolchain to barf on any file that tries to sneak in an FPU
instruction. I have already added '-isa=sh4-nofpu' to the assembler to
ensure this and I would like to do something similar for the linker to
make doubly sure. At present there is no provision for this sort of
thing and adding such an option would require messing with the
MERGE_MACH stuff to some degree. I would like it if whatever mechanism
emerges from this discussion did not proclude such a feature.

(It would also be nice to detect mixed ABIs as well, but that is an
orthogonal issue - except that it would require some work to the linker
and some sort of label on the file.)

-- 
Andrew Stubbs
andrew.stubbs@superh.com


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