This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: Broken SH2a patches
- From: Andrew STUBBS <andrew dot stubbs at st dot com>
- To: "'Nick Clifton'" <nickc at redhat dot com>
- Cc: "'Alexandre Oliva'" <aoliva at redhat dot com>, <binutils at sources dot redhat dot com>, "'Joern RENNECKE'" <joern dot rennecke at st dot com>
- Date: Wed, 5 Jan 2005 13:22:59 -0000
- Subject: RE: Broken SH2a patches
- Organization: STMicroelectronics
The patch is good but I spotted a mistake in the test results:
+ sh.s -isa=sh2a-nofpu-or-sh3-nommu
sh2a-nofpu-or-sh4-nommu-nofpu
There are similar mistakes for most of the results for this -isa option.
I have traced this to here:
! #define arch_sh2a_nofpu_or_sh4_nommu_nofpu
(arch_sh2a_sh3_base|arch_sh_no_mmu |arch_sh_no_co)
! #define arch_sh2a_nofpu_or_sh3_nommu
(arch_sh2a_sh3_base|arch_sh_no_mmu |arch_sh_no_co)
Note that both architectures have the same flags.
I'm in the process or testing it further.
--
------------------------------------------------------------------------
| Andrew Stubbs, | E-mail: Andrew.Stubbs@st.com |
| STMicroelectronics (R&D) Ltd., | or Andrew.Stubbs@superh.com |
| 1000 Aztec West, | |
| Almondsbury, | Tel: +44 (0)1454 462611 |
| Bristol, BS32 4SQ, U.K. | Fax: +44 (0)1454 462305 |
------------------------------------------------------------------------
> -----Original Message-----
> From: Nick Clifton [mailto:nickc@redhat.com]
> Sent: 20 December 2004 17:24
> To: Andrew STUBBS
> Cc: 'Alexandre Oliva'; binutils@sources.redhat.com; 'Joern RENNECKE'
> Subject: Re: Broken SH2a patches
>
>
> Hi Andrew,
>
> > Whatever technique we use it needs to be able to select an
> > architecture, based on the instructions in the file, that
> > specifies what architecture the file will run on, without
> > excluding any other similar, but different, architectures
> > that it may also run on (hence the fake architectures). Any
> > ideas?
>
> The simplest and most extensible scheme would be to drop the
> different machine values altogether. Just have one
> bfd_mach_sh number
> and one EF_SH_ number. Instead binary files would have a new .note
> section which contains an extensible bit mask of the architectures on
> which the instructions in that file can be run. When two or
> more files
> are combined this mask would be ANDed together to give the
> mask for the
> output binary and checked via XOR for incompatibilities.
>
> Each instruction would also need one of these bitmasks.
> When a new
> architecture is added every instruction's bitmask would have to be
> updated if it was supported by the new architecture. This would only
> have to be done once though and there are macros that could
> be defined
> to make it simpler.
>
> Anyway attached is a revised patch that includes your diagram of the
> dependencies (thanks) as well as some new base values and a
> fixed set of
> architecture definitions. (The problem you noticed with the
> -isa=sh2e
> selecting the sh2a-or-sh3e architecture was that the original
> definition
> of arch_sh2e defined it in terms of both sh2e_base and sh2a_base).
>
> I have also tweaked the #defines for the various base architecture
> values so it should be easier to add new ones in the future.
>
> What do you think of this version ?
>
> Cheers
> Nick
>
>
>