| Message ID | 1459885521-25434-1-git-send-email-heyleke@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
Hello, On Tue, 5 Apr 2016 21:45:18 +0200, Jan Heylen wrote: > extend the toolchain wrapper to also wrap the ld linker. > > Tested with gnu ld and gnu 'gold' > BR2_BINUTILS_EXTRA_CONFIG_OPTIONS="--enable-gold=default --enable-plugins" > > make host-binutils result in: (ld and ld.gold are equal) > <ARCH>-buildroot-linux-uclibc-ld -> toolchain-wrapper > <ARCH>-buildroot-linux-uclibc-ld.bfd > <ARCH>-buildroot-linux-uclibc-ld.br_real > <ARCH>-buildroot-linux-uclibc-ld.gold -> toolchain-wrapper > <ARCH>-buildroot-linux-uclibc-ld.gold.br_real > <ARCH>-linux-ld -> toolchain-wrapper > <ARCH>-linux-ld.br_real -> <ARCH>-buildroot-linux-uclibc-ld.br_real > <ARCH>-linux-ld.gold -> toolchain-wrapper > <ARCH>-linux-ld.gold.br_real -> <ARCH>-buildroot-linux-uclibc-ld.gold.br_real > toolchain-wrapper > > after host-gcc-initial, toolchain-wrapper will be rebuild, but the ld > symlinks remain > > Based upon patch from Thomas Petazzoni: > http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/60942 We had a discussion at the Buildroot Developers meeting today about this patch series. After discussion, we concluded that there should be no need to wrap ld. ld should not be used directly, except in very specific cases, where the caller knows what it is doing and should pass the right arguments. As far as we know, the only case that was broken was the libiscsi package, but such a package should definitely *not* use ld directly. So the fix should be done in libiscsi, not in the wrapper. However, your patch series triggered a very useful discussion about reworking how flags are handled by the wrapper, and we took the following notes of things to do: - We want to refactor how the CFLAGS are handled by the wrapper: - Combine BR2_TARGET_OPTIMIZATION and BR2_TARGET_LDFLAGS into a single BR2_TARGET_EXTRA_FLAGS - Have a make variable called TARGET_WRAPPER_FLAGS that includes all flags we want to include in the wrapper: * $(TARGET_ABI) * $(TARGET_CPPFLAGS) * $(BR2_TARGET_EXTRA_FLAGS) * Custom flags added by package/Makefile.in $(TARGET_OPTIMIZATION) and $(TARGET_DEBUGGING) are *NOT* in the wrapper. - TARGET_CFLAGS = $(TARGET_WRAPPER_CFLAGS) $(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING) TARGET_CXXFLAGS = $(TARGET_CFLAGS) TARGET_LDFLAGS = $(TARGET_CFLAGS) TARGET_FCFLAGS = $(TARGET_CFLAGS) - The wrapper, instead of having special cases for different flags, just receives (at build time), the list of hardcoded flag. A special logic needs to be put in place to handle precious flags (mcpu, march, mtune, mfloat-abi, etc.), for which the command-line passed flag must be preserved if passed. - Define LD to "false" in $(TARGET_CONFIGURE_OPTS) so that we detect the crappy packages that use LD directly. Individual packages can still pass LD=$(TARGET_LD) or LD=$(TARGET_CC) if really needed. We're of course not asking you to work on those topics. Arnout has volunteered to do it already. Best regards, Thomas
So we should fix libdmalloc as well? On 16 Oct 2016 12:05 pm, "Thomas Petazzoni" < thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Tue, 5 Apr 2016 21:45:18 +0200, Jan Heylen wrote: > > extend the toolchain wrapper to also wrap the ld linker. > > > > Tested with gnu ld and gnu 'gold' > > BR2_BINUTILS_EXTRA_CONFIG_OPTIONS="--enable-gold=default > --enable-plugins" > > > > make host-binutils result in: (ld and ld.gold are equal) > > <ARCH>-buildroot-linux-uclibc-ld -> toolchain-wrapper > > <ARCH>-buildroot-linux-uclibc-ld.bfd > > <ARCH>-buildroot-linux-uclibc-ld.br_real > > <ARCH>-buildroot-linux-uclibc-ld.gold -> toolchain-wrapper > > <ARCH>-buildroot-linux-uclibc-ld.gold.br_real > > <ARCH>-linux-ld -> toolchain-wrapper > > <ARCH>-linux-ld.br_real -> <ARCH>-buildroot-linux-uclibc-ld.br_real > > <ARCH>-linux-ld.gold -> toolchain-wrapper > > <ARCH>-linux-ld.gold.br_real -> <ARCH>-buildroot-linux-uclibc- > ld.gold.br_real > > toolchain-wrapper > > > > after host-gcc-initial, toolchain-wrapper will be rebuild, but the ld > > symlinks remain > > > > Based upon patch from Thomas Petazzoni: > > http://thread.gmane.org/gmane.comp.lib.uclibc.buildroot/60942 > > We had a discussion at the Buildroot Developers meeting today about > this patch series. After discussion, we concluded that there should be > no need to wrap ld. ld should not be used directly, except in very > specific cases, where the caller knows what it is doing and should pass > the right arguments. > > As far as we know, the only case that was broken was the libiscsi > package, but such a package should definitely *not* use ld directly. So > the fix should be done in libiscsi, not in the wrapper. > > However, your patch series triggered a very useful discussion about > reworking how flags are handled by the wrapper, and we took the > following notes of things to do: > > - We want to refactor how the CFLAGS are handled by the wrapper: > > - Combine BR2_TARGET_OPTIMIZATION and BR2_TARGET_LDFLAGS into a > single BR2_TARGET_EXTRA_FLAGS > > - Have a make variable called TARGET_WRAPPER_FLAGS that includes > all flags we want to include in the wrapper: > > * $(TARGET_ABI) > * $(TARGET_CPPFLAGS) > * $(BR2_TARGET_EXTRA_FLAGS) > * Custom flags added by package/Makefile.in > > $(TARGET_OPTIMIZATION) and $(TARGET_DEBUGGING) are *NOT* in the > wrapper. > > - TARGET_CFLAGS = $(TARGET_WRAPPER_CFLAGS) $(TARGET_OPTIMIZATION) > $(TARGET_DEBUGGING) > TARGET_CXXFLAGS = $(TARGET_CFLAGS) > TARGET_LDFLAGS = $(TARGET_CFLAGS) > TARGET_FCFLAGS = $(TARGET_CFLAGS) > > - The wrapper, instead of having special cases for different flags, > just receives (at build time), the list of hardcoded flag. A > special logic needs to be put in place to handle precious flags > (mcpu, march, mtune, mfloat-abi, etc.), for which the > command-line passed flag must be preserved if passed. > > - Define LD to "false" in $(TARGET_CONFIGURE_OPTS) so that we detect > the crappy packages that use LD directly. Individual packages can > still pass LD=$(TARGET_LD) or LD=$(TARGET_CC) if really needed. > > We're of course not asking you to work on those topics. Arnout has > volunteered to do it already. > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com >
Hello,
On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote:
> So we should fix libdmalloc as well?
Vicente is working on this. Do you have references to autobuilder
failures on libdmalloc caused by this problem ?
Thanks!
Thomas
Hello Jan, have you recently seen the dmalloc package failing because of using the wrong emulation in ld? Or because using ld instead of gcc for linking, in general? Indeed it uses ld instead of gcc, and that's something that could be improved upstream. However, since it's not failing to build for us I think there is nothing we need to fix in Buildroot. Regards, Vincent. On 16/10/16 14:28, Thomas Petazzoni wrote: > Hello, > > On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote: >> So we should fix libdmalloc as well? > > Vicente is working on this. Do you have references to autobuilder > failures on libdmalloc caused by this problem ? > > Thanks! > > Thomas >
For our platform (mips octeon 64 bit but with 32bit userspace: -mabi=n32), and indeed because of the usage of LD, the compilation does fail, that is why I added the patches. br, Jan On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera <Vincent.Riera@imgtec.com> wrote: > Hello Jan, > > have you recently seen the dmalloc package failing because of using the > wrong emulation in ld? Or because using ld instead of gcc for linking, > in general? > > Indeed it uses ld instead of gcc, and that's something that could be > improved upstream. However, since it's not failing to build for us I > think there is nothing we need to fix in Buildroot. > > Regards, > > Vincent. > > On 16/10/16 14:28, Thomas Petazzoni wrote: >> Hello, >> >> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote: >>> So we should fix libdmalloc as well? >> >> Vicente is working on this. Do you have references to autobuilder >> failures on libdmalloc caused by this problem ? >> >> Thanks! >> >> Thomas >>
Hello Jan, I have just built the dmalloc package for mips64r2 n32 little-endian and big-endian without any issue. I have used the "Codescape MTI" external toolchain. Are you using a different toolchain? Please let me know so I can reproduce the problem. Regards, Vincent. On 16/10/16 17:00, Jan Heylen wrote: > For our platform (mips octeon 64 bit but with 32bit userspace: > -mabi=n32), and indeed because of the usage of LD, the compilation > does fail, that is why I added the patches. > > br, > > Jan > > On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera > <Vincent.Riera@imgtec.com> wrote: >> Hello Jan, >> >> have you recently seen the dmalloc package failing because of using the >> wrong emulation in ld? Or because using ld instead of gcc for linking, >> in general? >> >> Indeed it uses ld instead of gcc, and that's something that could be >> improved upstream. However, since it's not failing to build for us I >> think there is nothing we need to fix in Buildroot. >> >> Regards, >> >> Vincent. >> >> On 16/10/16 14:28, Thomas Petazzoni wrote: >>> Hello, >>> >>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote: >>>> So we should fix libdmalloc as well? >>> >>> Vicente is working on this. Do you have references to autobuilder >>> failures on libdmalloc caused by this problem ? >>> >>> Thanks! >>> >>> Thomas >>>
I'm using a toolchain coming from Cavium, so you're saying that either the toolchain is the issue or it is no longer an issue? It's been some time ago that I tested this, let me come back to you later this week. br, Jan On Sun, Oct 16, 2016 at 5:15 PM, Vicente Olivert Riera <Vincent.Riera@imgtec.com> wrote: > Hello Jan, > > I have just built the dmalloc package for mips64r2 n32 little-endian and > big-endian without any issue. I have used the "Codescape MTI" external > toolchain. Are you using a different toolchain? Please let me know so I > can reproduce the problem. > > Regards, > > Vincent. > > On 16/10/16 17:00, Jan Heylen wrote: >> For our platform (mips octeon 64 bit but with 32bit userspace: >> -mabi=n32), and indeed because of the usage of LD, the compilation >> does fail, that is why I added the patches. >> >> br, >> >> Jan >> >> On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera >> <Vincent.Riera@imgtec.com> wrote: >>> Hello Jan, >>> >>> have you recently seen the dmalloc package failing because of using the >>> wrong emulation in ld? Or because using ld instead of gcc for linking, >>> in general? >>> >>> Indeed it uses ld instead of gcc, and that's something that could be >>> improved upstream. However, since it's not failing to build for us I >>> think there is nothing we need to fix in Buildroot. >>> >>> Regards, >>> >>> Vincent. >>> >>> On 16/10/16 14:28, Thomas Petazzoni wrote: >>>> Hello, >>>> >>>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote: >>>>> So we should fix libdmalloc as well? >>>> >>>> Vicente is working on this. Do you have references to autobuilder >>>> failures on libdmalloc caused by this problem ? >>>> >>>> Thanks! >>>> >>>> Thomas >>>>
On 16/10/16 17:19, Jan Heylen wrote: > I'm using a toolchain coming from Cavium, so you're saying that either > the toolchain is the issue or it is no longer an issue? It's been some > time ago that I tested this, let me come back to you later this week. Ok. Just for the record, no problem with the buildroot internal toolchain either. dmalloc built for mips64r2 n32 little-endian uclibc-ng. Regards, Vincent. > br, > > Jan > > On Sun, Oct 16, 2016 at 5:15 PM, Vicente Olivert Riera > <Vincent.Riera@imgtec.com> wrote: >> Hello Jan, >> >> I have just built the dmalloc package for mips64r2 n32 little-endian and >> big-endian without any issue. I have used the "Codescape MTI" external >> toolchain. Are you using a different toolchain? Please let me know so I >> can reproduce the problem. >> >> Regards, >> >> Vincent. >> >> On 16/10/16 17:00, Jan Heylen wrote: >>> For our platform (mips octeon 64 bit but with 32bit userspace: >>> -mabi=n32), and indeed because of the usage of LD, the compilation >>> does fail, that is why I added the patches. >>> >>> br, >>> >>> Jan >>> >>> On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera >>> <Vincent.Riera@imgtec.com> wrote: >>>> Hello Jan, >>>> >>>> have you recently seen the dmalloc package failing because of using the >>>> wrong emulation in ld? Or because using ld instead of gcc for linking, >>>> in general? >>>> >>>> Indeed it uses ld instead of gcc, and that's something that could be >>>> improved upstream. However, since it's not failing to build for us I >>>> think there is nothing we need to fix in Buildroot. >>>> >>>> Regards, >>>> >>>> Vincent. >>>> >>>> On 16/10/16 14:28, Thomas Petazzoni wrote: >>>>> Hello, >>>>> >>>>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote: >>>>>> So we should fix libdmalloc as well? >>>>> >>>>> Vicente is working on this. Do you have references to autobuilder >>>>> failures on libdmalloc caused by this problem ? >>>>> >>>>> Thanks! >>>>> >>>>> Thomas >>>>>
Hi,
ok, I just realized I won't have time 'later this week', so I had a look at
this again right away (#GTD it is called in hipster language). Did you
check the output of the build for dmalloc? I just verified the issue with
our toolchain, and the result is indeed that dmalloc 'builds', but if you
look at the .so file:
-rw-r--r-- 1 jheylen we2 849476 16 okt 19:04 libdmalloc.a
-rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmalloc.so
-rwxr-xr-x 1 jheylen we2 593 16 okt 19:05 libdmalloc.so.t
-rw-r--r-- 1 jheylen we2 858132 16 okt 19:04 libdmallocth.a
-rw-r--r-- 1 jheylen we2 915054 16 okt 19:04 libdmallocthcxx.a
-rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocthcxx.so
-rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocth.so
-rw-r--r-- 1 jheylen we2 906398 16 okt 19:04 libdmallocxx.a
-rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocxx.so
The sizes look suspicious ;-), if I try them on target, it doesn't work,
and readelf -a libdmalloc.so:
----------------------------
ELF Header:
Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x40
Start of program headers: 0 (bytes into file)
Start of section headers: 96 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 64 (bytes)
Number of section headers: 4
Section header string table index: 1
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .shstrtab STRTAB 0000000000000000 00000040
000000000000001b 0000000000000000 0 0 1
[ 2] .symtab SYMTAB 0000000000000000 00000160
00000000000000c0 0000000000000018 3 2 8
[ 3] .strtab STRTAB 0000000000000000 00000220
0000000000000031 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
There are no section groups in this file.
There are no program headers in this file.
There are no relocations in this file.
The decoding of unwind sections for machine type MIPS R3000 is not
currently supported.
Symbol table '.symtab' contains 8 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000018030 0 NOTYPE LOCAL DEFAULT ABS _gp
2: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _fdata
3: 0000000000000040 0 NOTYPE GLOBAL DEFAULT ABS _ftext
4: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
5: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _edata
6: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _end
7: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _fbss
No version information found in this file.
----------------------------
from configure log and config.log, you see why dmalloc decides to link with
-G -o:
checking shared library link args...
<buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld -G -o $@.t
checking shared library extension... so
<buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld:
conftest.a(conftest.o): ABI is incompatible with that of the selected
emulation: "elf32-ntradbigmips" != "elf64- tradbigmips"
<buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: failed to
merge target specific data of file conftest.a(conftest.o)
<buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: unrecognized
option '-all'
<buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: use the
--help option for usage information
444 configure:4475:
result: <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld -G -o
$@.t
from an earlier conversation on the subject:
If I patch dmalloc.mk: (to test the underlying issue):
-DMALLOC_CONF_ENV = CFLAGS="$(DMALLOC_CFLAGS)"
+DMALLOC_CONF_ENV = CFLAGS="$(DMALLOC_CFLAGS)"
TARGET_LD="$(TARGET_LD) -m elf32btsmipn32 "
define DMALLOC_POST_PATCH
$(SED) 's/^ac_cv_page_size=0$$/ac_cv_page_size=12/' $(@D)/configure
- $(SED) 's/(ld -/($${LD-ld} -/' $(@D)/configure
- $(SED) 's/'\''ld -/"$${LD-ld}"'\'' -/' $(@D)/configure
+ $(SED) 's/(ld -/($${TARGET_LD-ld} -/' $(@D)/configure
+ $(SED) 's/'\''ld -/"$${TARGET_LD-ld}"'\'' -/' $(@D)/configure
$(SED) 's/ar cr/$$(AR) cr/' $(@D)/Makefile.in
endef
I found in the config.log:
configure:4475: result:
/repo/buildroot-ngsw/output/host/usr/bin/mips64-octeon-linux-gnu-ld -m
elf32btsmipn32 -shared --whole-archive -soname $@ -o $@.t
which is what was expected.
Can you verify this in your referred toolchains and dmalloc builds?
thx,
Jan
On Sun, Oct 16, 2016 at 5:33 PM, Vicente Olivert Riera <
Vincent.Riera@imgtec.com> wrote:
> On 16/10/16 17:19, Jan Heylen wrote:
> > I'm using a toolchain coming from Cavium, so you're saying that either
> > the toolchain is the issue or it is no longer an issue? It's been some
> > time ago that I tested this, let me come back to you later this week.
>
> Ok. Just for the record, no problem with the buildroot internal
> toolchain either. dmalloc built for mips64r2 n32 little-endian uclibc-ng.
>
> Regards,
>
> Vincent.
>
> > br,
> >
> > Jan
> >
> > On Sun, Oct 16, 2016 at 5:15 PM, Vicente Olivert Riera
> > <Vincent.Riera@imgtec.com> wrote:
> >> Hello Jan,
> >>
> >> I have just built the dmalloc package for mips64r2 n32 little-endian and
> >> big-endian without any issue. I have used the "Codescape MTI" external
> >> toolchain. Are you using a different toolchain? Please let me know so I
> >> can reproduce the problem.
> >>
> >> Regards,
> >>
> >> Vincent.
> >>
> >> On 16/10/16 17:00, Jan Heylen wrote:
> >>> For our platform (mips octeon 64 bit but with 32bit userspace:
> >>> -mabi=n32), and indeed because of the usage of LD, the compilation
> >>> does fail, that is why I added the patches.
> >>>
> >>> br,
> >>>
> >>> Jan
> >>>
> >>> On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera
> >>> <Vincent.Riera@imgtec.com> wrote:
> >>>> Hello Jan,
> >>>>
> >>>> have you recently seen the dmalloc package failing because of using
> the
> >>>> wrong emulation in ld? Or because using ld instead of gcc for linking,
> >>>> in general?
> >>>>
> >>>> Indeed it uses ld instead of gcc, and that's something that could be
> >>>> improved upstream. However, since it's not failing to build for us I
> >>>> think there is nothing we need to fix in Buildroot.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Vincent.
> >>>>
> >>>> On 16/10/16 14:28, Thomas Petazzoni wrote:
> >>>>> Hello,
> >>>>>
> >>>>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote:
> >>>>>> So we should fix libdmalloc as well?
> >>>>>
> >>>>> Vicente is working on this. Do you have references to autobuilder
> >>>>> failures on libdmalloc caused by this problem ?
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Thomas
> >>>>>
>
Hi Vincent, any update on the libdmalloc issue we observe when building for MIPS (because of no ld wrapper) ? Do you see the same? br, Jan On Sun, Oct 16, 2016 at 7:27 PM, Jan Heylen <heyleke@gmail.com> wrote: > Hi, > > ok, I just realized I won't have time 'later this week', so I had a look > at this again right away (#GTD it is called in hipster language). Did you > check the output of the build for dmalloc? I just verified the issue with > our toolchain, and the result is indeed that dmalloc 'builds', but if you > look at the .so file: > > -rw-r--r-- 1 jheylen we2 849476 16 okt 19:04 libdmalloc.a > -rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmalloc.so > -rwxr-xr-x 1 jheylen we2 593 16 okt 19:05 libdmalloc.so.t > -rw-r--r-- 1 jheylen we2 858132 16 okt 19:04 libdmallocth.a > -rw-r--r-- 1 jheylen we2 915054 16 okt 19:04 libdmallocthcxx.a > -rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocthcxx.so > -rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocth.so > -rw-r--r-- 1 jheylen we2 906398 16 okt 19:04 libdmallocxx.a > -rwxr-xr-x 1 jheylen we2 593 16 okt 19:04 libdmallocxx.so > > The sizes look suspicious ;-), if I try them on target, it doesn't work, > and readelf -a libdmalloc.so: > ---------------------------- > ELF Header: > Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00 > Class: ELF64 > Data: 2's complement, big endian > Version: 1 (current) > OS/ABI: UNIX - System V > ABI Version: 0 > Type: DYN (Shared object file) > Machine: MIPS R3000 > Version: 0x1 > Entry point address: 0x40 > Start of program headers: 0 (bytes into file) > Start of section headers: 96 (bytes into file) > Flags: 0x0 > Size of this header: 64 (bytes) > Size of program headers: 0 (bytes) > Number of program headers: 0 > Size of section headers: 64 (bytes) > Number of section headers: 4 > Section header string table index: 1 > > Section Headers: > [Nr] Name Type Address Offset > Size EntSize Flags Link Info Align > [ 0] NULL 0000000000000000 00000000 > 0000000000000000 0000000000000000 0 0 0 > [ 1] .shstrtab STRTAB 0000000000000000 00000040 > 000000000000001b 0000000000000000 0 0 1 > [ 2] .symtab SYMTAB 0000000000000000 00000160 > 00000000000000c0 0000000000000018 3 2 8 > [ 3] .strtab STRTAB 0000000000000000 00000220 > 0000000000000031 0000000000000000 0 0 1 > Key to Flags: > W (write), A (alloc), X (execute), M (merge), S (strings) > I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) > O (extra OS processing required) o (OS specific), p (processor specific) > > There are no section groups in this file. > > There are no program headers in this file. > > There are no relocations in this file. > > The decoding of unwind sections for machine type MIPS R3000 is not > currently supported. > > Symbol table '.symtab' contains 8 entries: > Num: Value Size Type Bind Vis Ndx Name > 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND > 1: 0000000000018030 0 NOTYPE LOCAL DEFAULT ABS _gp > 2: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _fdata > 3: 0000000000000040 0 NOTYPE GLOBAL DEFAULT ABS _ftext > 4: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > 5: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _edata > 6: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _end > 7: 0000000000010040 0 NOTYPE GLOBAL DEFAULT ABS _fbss > > No version information found in this file. > ---------------------------- > > from configure log and config.log, you see why dmalloc decides to link > with -G -o: > > checking shared library link args... <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld > -G -o $@.t > checking shared library extension... so > > <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: > conftest.a(conftest.o): ABI is incompatible with that of the selected > emulation: "elf32-ntradbigmips" != "elf64- tradbigmips" > <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: failed to > merge target specific data of file conftest.a(conftest.o) > <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: unrecognized > option '-all' > <buildroot>/output/host/usr/bin/mips64-octeon-linux-gnu-ld: use the > --help option for usage information > 444 configure:4475: result: <buildroot>/output/ > host/usr/bin/mips64-octeon-linux-gnu-ld -G -o $@.t > > > > from an earlier conversation on the subject: > > If I patch dmalloc.mk: (to test the underlying issue): > > -DMALLOC_CONF_ENV = CFLAGS="$(DMALLOC_CFLAGS)" > +DMALLOC_CONF_ENV = CFLAGS="$(DMALLOC_CFLAGS)" > TARGET_LD="$(TARGET_LD) -m elf32btsmipn32 " > > define DMALLOC_POST_PATCH > $(SED) 's/^ac_cv_page_size=0$$/ac_cv_page_size=12/' > $(@D)/configure > - $(SED) 's/(ld -/($${LD-ld} -/' $(@D)/configure > - $(SED) 's/'\''ld -/"$${LD-ld}"'\'' -/' $(@D)/configure > + $(SED) 's/(ld -/($${TARGET_LD-ld} -/' $(@D)/configure > + $(SED) 's/'\''ld -/"$${TARGET_LD-ld}"'\'' -/' $(@D)/configure > $(SED) 's/ar cr/$$(AR) cr/' $(@D)/Makefile.in > endef > > I found in the config.log: > configure:4475: result: > /repo/buildroot-ngsw/output/host/usr/bin/mips64-octeon-linux-gnu-ld -m > elf32btsmipn32 -shared --whole-archive -soname $@ -o $@.t > > which is what was expected. > > > Can you verify this in your referred toolchains and dmalloc builds? > > thx, > > Jan > > On Sun, Oct 16, 2016 at 5:33 PM, Vicente Olivert Riera < > Vincent.Riera@imgtec.com> wrote: > >> On 16/10/16 17:19, Jan Heylen wrote: >> > I'm using a toolchain coming from Cavium, so you're saying that either >> > the toolchain is the issue or it is no longer an issue? It's been some >> > time ago that I tested this, let me come back to you later this week. >> >> Ok. Just for the record, no problem with the buildroot internal >> toolchain either. dmalloc built for mips64r2 n32 little-endian uclibc-ng. >> >> Regards, >> >> Vincent. >> >> > br, >> > >> > Jan >> > >> > On Sun, Oct 16, 2016 at 5:15 PM, Vicente Olivert Riera >> > <Vincent.Riera@imgtec.com> wrote: >> >> Hello Jan, >> >> >> >> I have just built the dmalloc package for mips64r2 n32 little-endian >> and >> >> big-endian without any issue. I have used the "Codescape MTI" external >> >> toolchain. Are you using a different toolchain? Please let me know so I >> >> can reproduce the problem. >> >> >> >> Regards, >> >> >> >> Vincent. >> >> >> >> On 16/10/16 17:00, Jan Heylen wrote: >> >>> For our platform (mips octeon 64 bit but with 32bit userspace: >> >>> -mabi=n32), and indeed because of the usage of LD, the compilation >> >>> does fail, that is why I added the patches. >> >>> >> >>> br, >> >>> >> >>> Jan >> >>> >> >>> On Sun, Oct 16, 2016 at 2:38 PM, Vicente Olivert Riera >> >>> <Vincent.Riera@imgtec.com> wrote: >> >>>> Hello Jan, >> >>>> >> >>>> have you recently seen the dmalloc package failing because of using >> the >> >>>> wrong emulation in ld? Or because using ld instead of gcc for >> linking, >> >>>> in general? >> >>>> >> >>>> Indeed it uses ld instead of gcc, and that's something that could be >> >>>> improved upstream. However, since it's not failing to build for us I >> >>>> think there is nothing we need to fix in Buildroot. >> >>>> >> >>>> Regards, >> >>>> >> >>>> Vincent. >> >>>> >> >>>> On 16/10/16 14:28, Thomas Petazzoni wrote: >> >>>>> Hello, >> >>>>> >> >>>>> On Sun, 16 Oct 2016 13:36:19 +0200, Jan Heylen wrote: >> >>>>>> So we should fix libdmalloc as well? >> >>>>> >> >>>>> Vicente is working on this. Do you have references to autobuilder >> >>>>> failures on libdmalloc caused by this problem ? >> >>>>> >> >>>>> Thanks! >> >>>>> >> >>>>> Thomas >> >>>>> >> > >
diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk index ca39f0b..2743175 100644 --- a/package/binutils/binutils.mk +++ b/package/binutils/binutils.mk @@ -82,6 +82,29 @@ HOST_BINUTILS_CONF_OPTS = \ $(BINUTILS_DISABLE_GDB_CONF_OPTS) \ $(BINUTILS_EXTRA_CONFIG_OPTIONS) +#TODO generalise this, this is in 3 places now... +HOST_BINUTILS_TOOLCHAIN_WRAPPER_ARGS += -DBR_CROSS_PATH_SUFFIX='".br_real"' +HOST_BINUTILS_POST_BUILD_HOOKS += TOOLCHAIN_BUILD_WRAPPER +HOST_BINUTILS_POST_INSTALL_HOOKS += HOST_BINUTILS_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS + +# Avoid that a .br_real is symlinked a second time. +define HOST_BINUTILS_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS + $(Q)cd $(HOST_DIR)/usr/bin; \ + for i in $(GNU_TARGET_NAME)-*; do \ + case "$$i" in \ + *.br_real) \ + ;; \ + *ld) \ + rm -f $$i.br_real; \ + mv $$i $$i.br_real; \ + ln -sf toolchain-wrapper $$i; \ + ln -sf toolchain-wrapper $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}; \ + ln -snf $$i.br_real $(ARCH)-linux$${i##$(GNU_TARGET_NAME)}.br_real; \ + ;; \ + esac; \ + done +endef + # binutils run configure script of subdirs at make time, so ensure # our TARGET_CONFIGURE_ARGS are taken into consideration for those define BINUTILS_BUILD_CMDS diff --git a/package/gcc/gcc-initial/gcc-initial.mk b/package/gcc/gcc-initial/gcc-initial.mk index 1e58d8b..62a2ef6 100644 --- a/package/gcc/gcc-initial/gcc-initial.mk +++ b/package/gcc/gcc-initial/gcc-initial.mk @@ -60,6 +60,7 @@ HOST_GCC_INITIAL_MAKE_OPTS += all-target-libgcc HOST_GCC_INITIAL_INSTALL_OPTS += install-target-libgcc endif +#rebuild the toolchain-wrapper (e.g. for ccache) already build once in binutils HOST_GCC_INITIAL_TOOLCHAIN_WRAPPER_ARGS += $(HOST_GCC_COMMON_TOOLCHAIN_WRAPPER_ARGS) HOST_GCC_INITIAL_POST_BUILD_HOOKS += TOOLCHAIN_BUILD_WRAPPER HOST_GCC_INITIAL_POST_INSTALL_HOOKS += HOST_GCC_INSTALL_WRAPPER_AND_SIMPLE_SYMLINKS diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk index ff4ae5e..7994808 100644 --- a/toolchain/toolchain-external/toolchain-external.mk +++ b/toolchain/toolchain-external/toolchain-external.mk @@ -741,7 +741,7 @@ define TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER *-ar|*-ranlib|*-nm) \ ln -sf $$(echo $$i | sed 's%^$(HOST_DIR)%../..%') .; \ ;; \ - *cc|*cc-*|*++|*++-*|*cpp) \ + *cc|*cc-*|*++|*++-*|*cpp|*ld) \ ln -sf toolchain-wrapper $$base; \ ;; \ *gdb|*gdbtui) \ diff --git a/toolchain/toolchain-wrapper.c b/toolchain/toolchain-wrapper.c index 887058f..ec069da 100644 --- a/toolchain/toolchain-wrapper.c +++ b/toolchain/toolchain-wrapper.c @@ -42,7 +42,7 @@ static char sysroot[PATH_MAX]; */ #define EXCLUSIVE_ARGS 3 -static char *predef_args[] = { +static char *gcc_predef_args[] = { #ifdef BR_CCACHE ccache_path, #endif @@ -80,6 +80,19 @@ static char *predef_args[] = { #endif }; +static char *ld_predef_args[] = { + path, +#ifdef BR_BINFMT_FLAT + "-elf2flt", +#endif +#ifdef BR_MIPS_TARGET_LITTLE_ENDIAN + "-EL", +#endif +#if defined(BR_MIPS_TARGET_BIG_ENDIAN) || defined(BR_ARC_TARGET_BIG_ENDIAN) + "-EB", +#endif +}; + static void check_unsafe_path(const char *path, int paranoid) { char **c; @@ -109,6 +122,8 @@ int main(int argc, char **argv) char *paranoid_wrapper; int paranoid; int ret, i, count = 0, debug; + int predef_args_sz; + int ld_wrapper; /* Calculate the relative paths */ basename = strrchr(progpath, '/'); @@ -169,7 +184,13 @@ int main(int argc, char **argv) return 3; } - cur = args = malloc(sizeof(predef_args) + + ld_wrapper = (strncmp("ld", basename + strlen(basename) - 2, 2) == 0) ? 1 : 0; + if (ld_wrapper) + predef_args_sz = sizeof(ld_predef_args); + else + predef_args_sz = sizeof(gcc_predef_args); + + cur = args = malloc(predef_args_sz + (sizeof(char *) * (argc + EXCLUSIVE_ARGS))); if (args == NULL) { perror(__FILE__ ": malloc"); @@ -177,42 +198,45 @@ int main(int argc, char **argv) } /* start with predefined args */ - memcpy(cur, predef_args, sizeof(predef_args)); - cur += sizeof(predef_args) / sizeof(predef_args[0]); + memcpy(cur, ld_wrapper ? ld_predef_args : gcc_predef_args, predef_args_sz); + cur += predef_args_sz / sizeof(char *); + /* following extras should only happen for non-ld wrappers */ + if (!ld_wrapper) { #ifdef BR_FLOAT_ABI - /* add float abi if not overridden in args */ - for (i = 1; i < argc; i++) { - if (!strncmp(argv[i], "-mfloat-abi=", strlen("-mfloat-abi=")) || - !strcmp(argv[i], "-msoft-float") || - !strcmp(argv[i], "-mhard-float")) - break; - } + /* add float abi if not overridden in args */ + for (i = 1; i < argc; i++) { + if (!strncmp(argv[i], "-mfloat-abi=", strlen("-mfloat-abi=")) || + !strcmp(argv[i], "-msoft-float") || + !strcmp(argv[i], "-mhard-float")) + break; + } - if (i == argc) - *cur++ = "-mfloat-abi=" BR_FLOAT_ABI; + if (i == argc) + *cur++ = "-mfloat-abi=" BR_FLOAT_ABI; #endif #if defined(BR_ARCH) || \ - defined(BR_CPU) - /* Add our -march/cpu flags, but only if none of - * -march/mtune/mcpu are already specified on the commandline - */ - for (i = 1; i < argc; i++) { - if (!strncmp(argv[i], "-march=", strlen("-march=")) || - !strncmp(argv[i], "-mtune=", strlen("-mtune=")) || - !strncmp(argv[i], "-mcpu=", strlen("-mcpu=" ))) - break; - } - if (i == argc) { + defined(BR_CPU) + /* Add our -march/cpu flags, but only if none of + * -march/mtune/mcpu are already specified on the commandline + */ + for (i = 1; i < argc; i++) { + if (!strncmp(argv[i], "-march=", strlen("-march=")) || + !strncmp(argv[i], "-mtune=", strlen("-mtune=")) || + !strncmp(argv[i], "-mcpu=", strlen("-mcpu=" ))) + break; + } + if (i == argc) { #ifdef BR_ARCH - *cur++ = "-march=" BR_ARCH; + *cur++ = "-march=" BR_ARCH; #endif #ifdef BR_CPU - *cur++ = "-mcpu=" BR_CPU; + *cur++ = "-mcpu=" BR_CPU; #endif - } + } #endif /* ARCH || CPU */ + } paranoid_wrapper = getenv("BR_COMPILER_PARANOID_UNSAFE_PATH"); if (paranoid_wrapper && strlen(paranoid_wrapper) > 0) @@ -252,7 +276,7 @@ int main(int argc, char **argv) exec_args = args; #ifdef BR_CCACHE - if (getenv("BR_NO_CCACHE")) + if (!ld_wrapper && getenv("BR_NO_CCACHE")) /* Skip the ccache call */ exec_args++; #endif @@ -268,12 +292,14 @@ int main(int argc, char **argv) if (debug > 0) { fprintf(stderr, "Toolchain wrapper executing:"); #ifdef BR_CCACHE_HASH - fprintf(stderr, "%sCCACHE_COMPILERCHECK='string:" BR_CCACHE_HASH "'", - (debug == 2) ? "\n " : " "); + if(!ld_wrapper) + fprintf(stderr, "%sCCACHE_COMPILERCHECK='string:" BR_CCACHE_HASH "'", + (debug == 2) ? "\n " : " "); #endif #ifdef BR_CCACHE_BASEDIR - fprintf(stderr, "%sCCACHE_BASEDIR='" BR_CCACHE_BASEDIR "'", - (debug == 2) ? "\n " : " "); + if(!ld_wrapper) + fprintf(stderr, "%sCCACHE_BASEDIR='" BR_CCACHE_BASEDIR "'", + (debug == 2) ? "\n " : " "); #endif for (i = 0; exec_args[i]; i++) fprintf(stderr, "%s'%s'", @@ -284,14 +310,14 @@ int main(int argc, char **argv) #ifdef BR_CCACHE_HASH /* Allow compilercheck to be overridden through the environment */ - if (setenv("CCACHE_COMPILERCHECK", "string:" BR_CCACHE_HASH, 0)) { + if (!ld_wrapper && setenv("CCACHE_COMPILERCHECK", "string:" BR_CCACHE_HASH, 0)) { perror(__FILE__ ": Failed to set CCACHE_COMPILERCHECK"); return 3; } #endif #ifdef BR_CCACHE_BASEDIR /* Allow compilercheck to be overridden through the environment */ - if (setenv("CCACHE_BASEDIR", BR_CCACHE_BASEDIR, 0)) { + if (!ld_wrapper && setenv("CCACHE_BASEDIR", BR_CCACHE_BASEDIR, 0)) { perror(__FILE__ ": Failed to set CCACHE_BASEDIR"); return 3; }