This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH 3/3] MIPS/GCC: Mark trailing labels with `.insn'
On Wed, 16 Nov 2016, Matthew Fortune wrote:
> > Based on this observation however I have determined that moving
> > multilib
> > and related flags such as `-mabi=n64' and possibly also `-Wl,-rpath,...'
> > from `$board_info(...,cflags)' over to `$board_info(...,multilib_flags)'
> > helps a bit and reduces the number of test suite issues, although still
> > causes occasional troubles with link tests where wrong multilib matching
> > happens in the absence of an exact match, such as with `-mabi=n64
> > -mmicromips' choosing the (o32) `-mmicromips' multilib which is not link
> > compatible rather than the (non-microMIPS) `-mabi=n64' which usually is
> > (with the minor issue of short delay slots in cross-mode jump
> > relaxation,
> > which might be solvable by the harness with the `-minterlink-compressed'
> > option where required).
>
> So have you been modifying the board file to add compile options? I
> normally just add them with --target_board=blah/-mabi=n64 which presumably
> places the options differently. I'll need to dig in to the code to see.
> Can you confirm your method of setting test options and the board file
> you are using?
Yes, I do set all the compiler flags within board description files
themselves, because not all flags possible are compatible with individual
board hardware, starting from the endianness. So I'd rather have a set of
prearranged self-contained board description files than having to choose
correct multilib flags each time on test suite invocation to match the
board selected (and vice versa), and possibly getting it wrong.
Also I having chains of multilib-specific `-Wl,-dynamic-linker,...' and
`-Wl,-rpath,...' options -- needed to get at the right dynamic libraries
from the sysroot on the target board -- passed on the command line is I
think all but convenient, especially given that the mapping between these
and the multilib selected with other compiler flags is bijective.
Anything beyond that, needed for specific testing (say to check whether a
change has not regressed `-mcode-readable=no' code generation on hardware
which accepts any `-mcode-readable=' setting) may still be specified on
the test suite invocation command line, or so I think at least.
> > These as well have been eliminated with the use of `multilib_flags'
> > although as I noted above I still see link failures from a wrong inexact
> > multilib selection sometimes.
>
> Incorrect multilib selection is always a risk when we have a partial set
> built especially under the current matching logic for multilibs. I have
> a complicated set of multi-lib updates to post that allow a multilib'd
> toolchain to 'know' about all possible incompatible multilibs but not
> necessarily build them all. This means that instead of getting a link
> failure because of linking against the wrong library you will not find
> the library in the first place. I don't have a good enough writeup nor
> test coverage for other multilib toolchain builds to post it yet though.
Having a full multilib set built is I think impractical, and some may not
even be fully supported although selectable. As long as we have a base
line though, such as a set of regular MIPS multilibs built across the ABIs
supported and both endiannesses, then we can always use them as the lowest
common denominator, downgrading any higher ISA level or ISA options
selected by a binary linked to those base-line multilibs, rather than
switching the ABI or the endianness by accident. But that requires a lot
of care in writing multilib selection recipes, as you have already
observed.
NB that is not limited to running the test suite only and may be useful
in the field too, e.g. to build a MIPS16 or microMIPS app occasionally and
make it use regular MIPS startup and system libraries where no respective
multilib has been configured in the compiler. That is supposed to work in
principle, and can usually still be achieved even with the driver being
confused about multilib selection, by carefully switching between the
relevant options at different build stages, i.e. compilation, assembly and
linking. It would be good if such jumping through the hoops could be
avoided though.
Maciej