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
