makefile target

Simon 'corecode' Schubert corecode at fs.ei.tum.de
Tue Aug 21 05:43:21 PDT 2007


km b wrote:
Ah.  You'll have to call them with OBJFORMAT_PREFIX defined.  We should probably include the path in the compile stage.  Without any prefix, these wrappers will default to using /usr/libexec/* binaries instead.
Is that the reason libc_r  build fails during linking stage? I am
getting error from assembler that incorrect register %rdx used with
'l' suffix? The libc_r/arch/amd64/_atomic_lock.s is causing this
error. If right assembler is used , this shouldn't happen.
I thought Noah fixed everything, so this shouldn't happen.

The `l' suffix is not appropriate for %rdx, because `l' means 32bit, AFAIK.  So there might be something wrong, not necessarily the assembler, however.

If you can explain OBJFORMAT_PREFIX a little bit more , that'll be gr8.
if you call objformat, it will check the basename of the binary used, i.e. /usr/bin/cc, /usr/bin/gcc, /usr/bin/as, etc.  Depending on this name it will decide whether the binary belongs to the compiler or whether it belongs to binutils.  Then, it will assemble the real path of the target binary, for instance /usr/libexec/gcc41/cc.  This works as follows.

real_binary = ${OBJFORMAT_PREFIX}/usr/libexec/${VERSION_PATH}/$0

with VERSION_PATH set to ${CCVER} if the binary is a compiler binary or to ${BINUTILSVER} if the binary is a binutils binary.  If any of CCVER,BINUTILSVER is not set, it will choose compiletime default values.

I think we should add the possibilty to set a compiletime default for OBJFORMAT_PREFIX (other than the empty string, like now) so that crossworld binaries will work as expected.  Right now Makefile.inc1 will set OBJFORMAT_PREFIX for the (cross)world stages, so that instead of /usr/libexec/*, the crosscompiler will be selected.

cheers
 simon




More information about the Kernel mailing list