| Message ID | 87wqziffpo.fsf@arh128.prevas.dk |
|---|---|
| State | Rejected |
| Headers | show |
Esben, All, On Tuesday 25 September 2012 14:29:39 Esben Haabendal wrote: > # HG changeset patch > # User Esben Haabendal <esben.haabendal@prevas.dk> > # Date 1348575902 -7200 > # Node ID 893b394644d2228baead66c2bb599f3ab1796a28 > # Parent f46a1d105896c89f697ff7f2c8ebb6b7b8403d5d > kernel/linux: change arch tuple to use -uclinux for uclinux toolchains > > This fixes at least ColdFire uClinux builds, as gcc filters out > all m68k no-mmu cpus for linux builds and (some) mmu cpus for uclinux > builds. > > Signed-off-by: "Esben Haabendal" <esben@haabendal.dk> > > diff -r f46a1d105896 -r 893b394644d2 scripts/build/kernel/linux.sh > --- a/scripts/build/kernel/linux.sh Sun Sep 23 11:59:28 2012 +0900 > +++ b/scripts/build/kernel/linux.sh Tue Sep 25 14:25:02 2012 +0200 > @@ -6,12 +6,7 @@ > if [ "${CT_ARCH_USE_MMU}" = "y" ]; then > CT_TARGET_KERNEL="linux" > else > - # Sometime, noMMU linux targets have a -uclinux tuple, while > - # sometime it's -linux. We currently have only one noMMU linux > - # target, and it uses -linux, so let's just use that. Time > - # to fix that later... > - # CT_TARGET_KERNEL="uclinux" > - CT_TARGET_KERNEL="linux" > + CT_TARGET_KERNEL="uclinux" > fi > } NAK. IIRC, the blackfin arch does not use '-uclinux', but '-linux': $ hg blame scripts/build/kernel/linux.sh [--SNIP--] 1345: CT_DoKernelTupleValues() { 1345: if [ "${CT_ARCH_USE_MMU}" = "y" ]; then 1345: CT_TARGET_KERNEL="linux" 1345: else 1910: # Sometime, noMMU linux targets have a -uclinux tuple, while 1910: # sometime it's -linux. We currently have only one noMMU linux 1910: # target, and it uses -linux, so let's just use that. Time 1910: # to fix that later... 1910: # CT_TARGET_KERNEL="uclinux" 1910: CT_TARGET_KERNEL="linux" 1345: fi 1345: } [--SNIP--] $ hg log -v -r 1910 --template '{desc}\n' Add basic support for the Blackfin architecture [--SNIP--] Apply the patch to the kernel/linux build script to use 'linux' in the noMMU tuples. See: http://sourceware.org/ml/crossgcc/2010-04/msg00010.html Basically, 'bfin-elf' is for bare-metal, 'bfin-uclinux' if for flat-binaries with no shared libs, and 'bfin-linux' for FDPIC-ELF that allows shared libs. So, if there are archs that want -uclinux, it has to be conditional. Regards, Yann E. MORIN.
On Tuesday 25 September 2012 12:41:42 Yann E. MORIN wrote: > Basically, 'bfin-elf' is for bare-metal, 'bfin-uclinux' if for > flat-binaries with no shared libs, and 'bfin-linux' for FDPIC-ELF that > allows shared libs. correct, the current convention is that "-uclinux" is for FLAT targets. although minor correction: most FLAT systems do support shared FLAT binaries, but they're a horrible abomination that few people use :). -mike
Mike Frysinger <vapier@gentoo.org> writes: > On Tuesday 25 September 2012 12:41:42 Yann E. MORIN wrote: >> Basically, 'bfin-elf' is for bare-metal, 'bfin-uclinux' if for >> flat-binaries with no shared libs, and 'bfin-linux' for FDPIC-ELF that >> allows shared libs. > > correct, the current convention is that "-uclinux" is for FLAT > targets. Ok, but where does this convention come from. Or rather, who follows this convention? It does not generally seem to be the convention used in GCC, at least not for all archs. If linux-gnu is linux with glibc, linux-uclibc is uClinux/FDPIC-ELF with uClibc, and uclinux-uclibc is uClinux/FLAT with uClibc. What arch tuple should then be used for linux with uClibc? I don't see the benefit of not being able to tell it apart from uClinux/FDPIC-ELF with uClibc. If you take a look at gcc/config.gcc it has stuff like -------- m68k-*-uclinuxoldabi*) # Motorola m68k/ColdFire running uClinux # with uClibc, using the original # m68k-elf-based ABI default_m68k_cpu=68020 default_cf_cpu=5206 tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/uclinux-oldabi.h glibc-stdint.h" tm_defines="${tm_defines} MOTOROLA=1" tmake_file="m68k/t-floatlib m68k/t-uclinux" ;; m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux # with uClibc, using the new GNU/Linux-style # ABI. default_m68k_cpu=68020 default_cf_cpu=5206 tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h flat.h m68k/linux.h m68k/uclinux.h ./sysroot-suffix.h" tm_defines="${tm_defines} MOTOROLA=1 UCLIBC_DEFAULT=1" extra_options="${extra_options} linux.opt" tmake_file="m68k/t-floatlib m68k/t-uclinux m68k/t-mlibs" ;; m68k-*-linux*) # Motorola m68k's running GNU/Linux # with ELF format using glibc 2 # aka the GNU/Linux C library 6. default_m68k_cpu=68020 default_cf_cpu=5475 with_arch=${with_arch:-m68k} tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h m68k/linux.h ./sysroot-suffix.h" extra_options="${extra_options} m68k/ieee.opt" tm_defines="${tm_defines} MOTOROLA=1" tmake_file="${tmake_file} m68k/t-floatlib m68k/t-linux m68k/t-mlibs" # if not configured with --enable-sjlj-exceptions, bump the # libgcc version number if test x$sjlj != x1; then tmake_file="$tmake_file m68k/t-slibgcc-elf-ver" fi ;; -------- I guess that mean that at least for m68k, the convention you mention is not shared with GCC. When building an m68k cross gcc, using *-*-linux-* will filter out any target devices that does not have the FL_MMU flag set (in gcc/config/m68k/m68k-devices.def). When building with *-*-uclinux-*, only those devices without FL_MMU flag set, or with FL_UCLINUX flag set will be available. As such, the convention does not work for m68k. As for my current needs, this can be made conditional for m68k. That said, I don't think the convention is the most sane one, as it would be best to have "linux-uclibc" mean the same thing independent of the cpu prefix, and also in line with the principle of least surprise, it would make sense to use "uclinux-*" for uclinux archs :-) /Esben -- For unsubscribe information see http://sourceware.org/lists.html#faq
On Tuesday 25 September 2012 14:18:38 Esben Haabendal wrote: > Mike Frysinger <vapier@gentoo.org> writes: > > On Tuesday 25 September 2012 12:41:42 Yann E. MORIN wrote: > >> Basically, 'bfin-elf' is for bare-metal, 'bfin-uclinux' if for > >> flat-binaries with no shared libs, and 'bfin-linux' for FDPIC-ELF that > >> allows shared libs. > > > > correct, the current convention is that "-uclinux" is for FLAT > > targets. > > Ok, but where does this convention come from. Or rather, who follows > this convention? > > It does not generally seem to be the convention used in GCC, at least > not for all archs. > > If linux-gnu is linux with glibc, linux-uclibc is uClinux/FDPIC-ELF with > uClibc, and uclinux-uclibc is uClinux/FLAT with uClibc. uClibc supports multiple file formats (including FDPIC-ELF and FLAT). if you see a toolchain end in "-uclinux" or "-uclibc*", you're pretty much guaranteed to be using uClibc. further, pretty much every target i've seen so far that ends in -uclinux was targeting the FLAT file format. for Blackfin targets, we wanted a new tuple when using FDPIC-ELF, so we went with linux-uclibc rather than uclinux. after all, when you're running Linux with the ELF format, the fact that you lack a MMU is largely transparent to userland (ignoring lack of fork). > What arch tuple should then be used for linux with uClibc? I don't see the > benefit of not being able to tell it apart from uClinux/FDPIC-ELF with > uClibc. i don't understand the question. "uclinux" means you're running Linux with uClibc, as does "linux-uclibc". > -------- > m68k-*-uclinuxoldabi*) # Motorola m68k/ColdFire running uClinux > # with uClibc, using the original > # m68k-elf-based ABI > default_m68k_cpu=68020 > default_cf_cpu=5206 > tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h > elfos.h m68k/uclinux-oldabi.h glibc-stdint.h" tm_defines="${tm_defines} > MOTOROLA=1" > tmake_file="m68k/t-floatlib m68k/t-uclinux" > ;; > m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux > # with uClibc, using the new > GNU/Linux-style # ABI. > default_m68k_cpu=68020 > default_cf_cpu=5206 > tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h > flat.h m68k/linux.h m68k/uclinux.h ./sysroot-suffix.h" > tm_defines="${tm_defines} MOTOROLA=1 UCLIBC_DEFAULT=1" > extra_options="${extra_options} linux.opt" > tmake_file="m68k/t-floatlib m68k/t-uclinux m68k/t-mlibs" > ;; > m68k-*-linux*) # Motorola m68k's running GNU/Linux > # with ELF format using glibc 2 > # aka the GNU/Linux C library 6. > default_m68k_cpu=68020 > default_cf_cpu=5475 > with_arch=${with_arch:-m68k} > tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h > m68k/linux.h ./sysroot-suffix.h" extra_options="${extra_options} > m68k/ieee.opt" > tm_defines="${tm_defines} MOTOROLA=1" > tmake_file="${tmake_file} m68k/t-floatlib m68k/t-linux > m68k/t-mlibs" # if not configured with --enable-sjlj-exceptions, bump the > # libgcc version number > if test x$sjlj != x1; then > tmake_file="$tmake_file m68k/t-slibgcc-elf-ver" > fi > ;; > -------- > > I guess that mean that at least for m68k, the convention you mention is > not shared with GCC. m68k doesn't support FDPIC-ELF. i don't know what you're trying to show. > When building an m68k cross gcc, using *-*-linux-* will filter out any > target devices that does not have the FL_MMU flag set (in > gcc/config/m68k/m68k-devices.def). When building with *-*-uclinux-*, > only those devices without FL_MMU flag set, or with FL_UCLINUX flag set > will be available. > > As such, the convention does not work for m68k. > > As for my current needs, this can be made conditional for m68k. > > That said, I don't think the convention is the most sane one, as it > would be best to have "linux-uclibc" mean the same thing independent of > the cpu prefix, and also in line with the principle of least surprise, > it would make sense to use "uclinux-*" for uclinux archs :-) looks to me like gcc only uses the FL_{MMU,UCLINUX} flags to figure out whether to build FLAT shared libraries. so if you want those things, use m68k- uclinux. if you don't want those things, then use whatever target you want. -mike
Mike Frysinger <vapier@gentoo.org> writes: > On Tuesday 25 September 2012 14:18:38 Esben Haabendal wrote: >> Mike Frysinger <vapier@gentoo.org> writes: >> > On Tuesday 25 September 2012 12:41:42 Yann E. MORIN wrote: >> >> Basically, 'bfin-elf' is for bare-metal, 'bfin-uclinux' if for >> >> flat-binaries with no shared libs, and 'bfin-linux' for FDPIC-ELF that >> >> allows shared libs. >> > >> > correct, the current convention is that "-uclinux" is for FLAT >> > targets. >> >> Ok, but where does this convention come from. Or rather, who follows >> this convention? >> >> It does not generally seem to be the convention used in GCC, at least >> not for all archs. >> >> If linux-gnu is linux with glibc, linux-uclibc is uClinux/FDPIC-ELF with >> uClibc, and uclinux-uclibc is uClinux/FLAT with uClibc. > > uClibc supports multiple file formats (including FDPIC-ELF and FLAT). > if you see a toolchain end in "-uclinux" or "-uclibc*", you're pretty > much guaranteed to be using uClibc. Yes. > further, pretty much every target i've seen so far that ends in -uclinux was > targeting the FLAT file format. You seem to miss the point I am making here. This is not true for m68k/coldfire. You must use *-*-uclinux-* to configure gcc for the non-mmu m68k/cf cpus. > for Blackfin targets, we wanted a new tuple when using FDPIC-ELF, so > we went with linux-uclibc rather than uclinux. after all, when you're > running Linux with the ELF format, the fact that you lack a MMU is > largely transparent to userland (ignoring lack of fork). Yes, I see that. But... >> What arch tuple should then be used for linux with uClibc? I don't see the >> benefit of not being able to tell it apart from uClinux/FDPIC-ELF with >> uClibc. > > i don't understand the question. "uclinux" means you're running Linux with > uClibc, as does "linux-uclibc". I dare to say "no". With *-*-uclinux-* you are saying you are running Linux without mmu. With *-*-linux-uclibc or *-*-uclinux-uclibc you are saying you are running Linux with uClibc. With some m68k cpus, you are able to use either Linux with glibc, Linux (with mmu) with uClibc, or Linux (without mmu, uCLinux) with uClibc. It would be rather handy to be able to use different arch tuples for all 3 cases. > >> -------- >> m68k-*-uclinuxoldabi*) # Motorola m68k/ColdFire running uClinux >> # with uClibc, using the original >> # m68k-elf-based ABI >> default_m68k_cpu=68020 >> default_cf_cpu=5206 >> tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h >> elfos.h m68k/uclinux-oldabi.h glibc-stdint.h" tm_defines="${tm_defines} >> MOTOROLA=1" >> tmake_file="m68k/t-floatlib m68k/t-uclinux" >> ;; >> m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux >> # with uClibc, using the new >> GNU/Linux-style # ABI. >> default_m68k_cpu=68020 >> default_cf_cpu=5206 >> tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h >> flat.h m68k/linux.h m68k/uclinux.h ./sysroot-suffix.h" >> tm_defines="${tm_defines} MOTOROLA=1 UCLIBC_DEFAULT=1" >> extra_options="${extra_options} linux.opt" >> tmake_file="m68k/t-floatlib m68k/t-uclinux m68k/t-mlibs" >> ;; >> m68k-*-linux*) # Motorola m68k's running GNU/Linux >> # with ELF format using glibc 2 >> # aka the GNU/Linux C library 6. >> default_m68k_cpu=68020 >> default_cf_cpu=5475 >> with_arch=${with_arch:-m68k} >> tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h >> m68k/linux.h ./sysroot-suffix.h" extra_options="${extra_options} >> m68k/ieee.opt" >> tm_defines="${tm_defines} MOTOROLA=1" >> tmake_file="${tmake_file} m68k/t-floatlib m68k/t-linux >> m68k/t-mlibs" # if not configured with --enable-sjlj-exceptions, bump the >> # libgcc version number >> if test x$sjlj != x1; then >> tmake_file="$tmake_file m68k/t-slibgcc-elf-ver" >> fi >> ;; >> -------- >> >> I guess that mean that at least for m68k, the convention you mention is >> not shared with GCC. > > m68k doesn't support FDPIC-ELF. i don't know what you're trying to > show. I am not just trying to show something, I am trying to build a working uclinux toolchain for coldfire. It doesn't really matter for that, that FDPIC-ELF is not supported, as the problem is here for FLAT. >> When building an m68k cross gcc, using *-*-linux-* will filter out any >> target devices that does not have the FL_MMU flag set (in >> gcc/config/m68k/m68k-devices.def). When building with *-*-uclinux-*, >> only those devices without FL_MMU flag set, or with FL_UCLINUX flag set >> will be available. >> >> As such, the convention does not work for m68k. >> >> As for my current needs, this can be made conditional for m68k. >> >> That said, I don't think the convention is the most sane one, as it >> would be best to have "linux-uclibc" mean the same thing independent of >> the cpu prefix, and also in line with the principle of least surprise, >> it would make sense to use "uclinux-*" for uclinux archs :-) > > looks to me like gcc only uses the FL_{MMU,UCLINUX} flags to figure > out whether to build FLAT shared libraries. No, gcc uses these flags combined with the arch tuples to sort out which cpu's that are available (for --with-cpu and -mcpu). Using linux-uclibc results in only having the FL_MMU cpus available. > so if you want those things, use m68k- uclinux. Exactly :-) I will rework the patch to set CT_TARGET_KERNEL depending on both CT_ARCH_USE_MMU and CT_ARCH. So "linux" for bfin and "uclinux" for m68k. /Esben -- For unsubscribe information see http://sourceware.org/lists.html#faq
On Tuesday 25 September 2012 17:18:31 Esben Haabendal wrote: > Mike Frysinger <vapier@gentoo.org> writes: > > On Tuesday 25 September 2012 14:18:38 Esben Haabendal wrote: > >> What arch tuple should then be used for linux with uClibc? I don't see > >> the benefit of not being able to tell it apart from uClinux/FDPIC-ELF > >> with uClibc. > > > > i don't understand the question. "uclinux" means you're running Linux > > with uClibc, as does "linux-uclibc". > > I dare to say "no". With *-*-uclinux-* you are saying you are running > Linux without mmu. With *-*-linux-uclibc or *-*-uclinux-uclibc you are > saying you are running Linux with uClibc. Linux is Linux. "uclinux" is a dead term which has no bearing anymore and hasn't for years. you run Linux w/mmu support turned on or turned off, but you're running Linux in either case. thus saying "Linux with uClibc" is meaningless to mmu status. Blackfin doesn't have a MMU and most likely never will. bfin-linux-uclibc is for running the FDPIC-ELF format with uClibc under Linux. we build with MMU support turned off, but *gcc* does not care at all either way. uClibc and Linux is configured with the MMU turned off. > With some m68k cpus, you are able to use either Linux with glibc, Linux > (with mmu) with uClibc, or Linux (without mmu, uCLinux) with uClibc. It > would be rather handy to be able to use different arch tuples for all 3 > cases. running Linux w/mmu support enabled on a processor with a MMU can execute code compiled for a system w/mmu disabled. there's no magic here, just a different file format (FLAT) and certain functions disabled (like fork). similarly, if a Blackfin processor was released with a MMU enabled, i could take all the code i already have compiled today and run it perfectly fine on that. > I will rework the patch to set CT_TARGET_KERNEL depending on both > CT_ARCH_USE_MMU and CT_ARCH. So "linux" for bfin and "uclinux" for > m68k. hard coding one way or the other is wrong. bfin-uclinux is valid, as is m68k- uclinux and arm-uclinux and mips-uclinux and many other targets. -mike
Mike Frysinger <vapier@gentoo.org> writes: >> I will rework the patch to set CT_TARGET_KERNEL depending on both >> CT_ARCH_USE_MMU and CT_ARCH. So "linux" for bfin and "uclinux" for >> m68k. > > hard coding one way or the other is wrong. bfin-uclinux is valid, as is m68k- > uclinux and arm-uclinux and mips-uclinux and many other targets. Well, the fact is that either GCC has to be changed to handle linux/uclinux in the arch tuple to your preferences, or ct-ng has to be able to handle it. The current situations makes ct-ng unable to build linux-uclibc for m68k cpus without mmu. So what do you propose? /Esben -- For unsubscribe information see http://sourceware.org/lists.html#faq
On Wednesday 26 September 2012 00:47:07 Esben Haabendal wrote: > Mike Frysinger <vapier@gentoo.org> writes: > >> I will rework the patch to set CT_TARGET_KERNEL depending on both > >> CT_ARCH_USE_MMU and CT_ARCH. So "linux" for bfin and "uclinux" for > >> m68k. > > > > hard coding one way or the other is wrong. bfin-uclinux is valid, as is > > m68k- uclinux and arm-uclinux and mips-uclinux and many other targets. > > Well, the fact is that either GCC has to be changed to handle > linux/uclinux in the arch tuple to your preferences, or ct-ng has to be > able to handle it. The current situations makes ct-ng unable to build > linux-uclibc for m68k cpus without mmu. i don't know what the selection of ct-ng looks like as i don't use it. i'm just clarifying incorrect statements made and giving background. if you want to target m68k systems running Linux w/out an mmu using the FLAT format, then "m68k-uclinux" is the tuple you want to use. hardcoding any arch around that logic is wrong. -mike
Mike Frysinger <vapier@gentoo.org> writes: > On Wednesday 26 September 2012 00:47:07 Esben Haabendal wrote: >> Mike Frysinger <vapier@gentoo.org> writes: >> >> I will rework the patch to set CT_TARGET_KERNEL depending on both >> >> CT_ARCH_USE_MMU and CT_ARCH. So "linux" for bfin and "uclinux" for >> >> m68k. >> > >> > hard coding one way or the other is wrong. bfin-uclinux is valid, as is >> > m68k- uclinux and arm-uclinux and mips-uclinux and many other targets. >> >> Well, the fact is that either GCC has to be changed to handle >> linux/uclinux in the arch tuple to your preferences, or ct-ng has to be >> able to handle it. The current situations makes ct-ng unable to build >> linux-uclibc for m68k cpus without mmu. > > i don't know what the selection of ct-ng looks like as i don't use it. i'm > just clarifying incorrect statements made and giving background. Yes, thank you, highly appreciated. I don't know why, but I somehow just assumed that FD_PIC_ELF were supported by m68k, but without support in both GCC or Linux I guess I was being slightly optimistic ;-) > if you want to target m68k systems running Linux w/out an mmu using > the FLAT format, then "m68k-uclinux" is the tuple you want to use. And that is exactly what we will do, which then requires a bit of logic to not mess up the bfin arch in ct-ng. /Esben -- For unsubscribe information see http://sourceware.org/lists.html#faq
diff -r f46a1d105896 -r 893b394644d2 scripts/build/kernel/linux.sh --- a/scripts/build/kernel/linux.sh Sun Sep 23 11:59:28 2012 +0900 +++ b/scripts/build/kernel/linux.sh Tue Sep 25 14:25:02 2012 +0200 @@ -6,12 +6,7 @@ if [ "${CT_ARCH_USE_MMU}" = "y" ]; then CT_TARGET_KERNEL="linux" else - # Sometime, noMMU linux targets have a -uclinux tuple, while - # sometime it's -linux. We currently have only one noMMU linux - # target, and it uses -linux, so let's just use that. Time - # to fix that later... - # CT_TARGET_KERNEL="uclinux" - CT_TARGET_KERNEL="linux" + CT_TARGET_KERNEL="uclinux" fi }
# HG changeset patch # User Esben Haabendal <esben.haabendal@prevas.dk> # Date 1348575902 -7200 # Node ID 893b394644d2228baead66c2bb599f3ab1796a28 # Parent f46a1d105896c89f697ff7f2c8ebb6b7b8403d5d kernel/linux: change arch tuple to use -uclinux for uclinux toolchains This fixes at least ColdFire uClinux builds, as gcc filters out all m68k no-mmu cpus for linux builds and (some) mmu cpus for uclinux builds. Signed-off-by: "Esben Haabendal" <esben@haabendal.dk> -- For unsubscribe information see http://sourceware.org/lists.html#faq