n32 support patches

C. Jayachandran c.jayachandran at gmail.com
Tue Mar 2 13:36:17 UTC 2010


On Tue, Mar 2, 2010 at 10:36 AM, M. Warner Losh <imp at bsdimp.com> wrote:
> In message: <dffe84831003012043n119d5809s2e300e4b8bc35a35 at mail.gmail.com>
>            Neel Natu <neelnatu at gmail.com> writes:
> : The changes to bsd.cpu.mk that append to LDFLAGS will most likely
> : break building kernel modules. Can you build a kernel module in a tree
> : with your patch?
>
> Chances are all of those will go away anyway :)  But I haven't thought
> about ABI changes in my TBEMD tree....
>
> : The problem is that LDFLAGS are directly passed as arguments to the
> : linker in bsd.kmod.mk and the linker does not like the
> : -Wl,-linker_option style of setting options.
> :
> : Do you really need to set LDFLAGS in bsd.cpu.mk? It would seem that
> : simply setting LD would work.
>
> But in the current world order, I have the same questions...

If you look at the bsd.lib.mk and bsd.prog.mk used for userspace
compilation, it seems that LDFLAGS are passed to ${CC} when creating
an final executable or library as I had written.  So for user-space
compilation we need the -Wl in LDFLAGS. In kmod.mk, LDFLAGS is passed
to ${LD} which will cause problems as Neel noted.

The easy fix is to clear LDFLAGS in kmod.mk, since ${LD} already has
the emulation flag.

The proper fix would be to have the emulation flags like
elf64btsmip_fbsd passed by the compiler to the linker, based on arch
and abi flags, and avoid using LDFLAGS for doing this.

But this still has a problem because the arch and abi settings are in
CFLAGS which is not passed in while creating shared libraries in
bsd.lib.mk, so shared libraries creation won't work. So for this to
completely work, we should not rely on CFLAGS either. Instead the
toolchain should have default abi and arch settings, based on the
target.

I think the proper fix would be needed anyway, as we should be able to
do 'cc x.c' on an n64 or n32 userspace and get an n64 or n32
executable, not o32 executable.

I will make a initial patch that removes the LDFLAGS from bsd.cpu.mk
and changes gcc/config/mips/freebsd.h to have the correct defaults,
and see how it works out.

Regards,
JC.


More information about the freebsd-mips mailing list