From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Heylen Date: Sun, 16 Oct 2016 19:27:48 +0200 Subject: [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper In-Reply-To: References: <1459885521-25434-1-git-send-email-heyleke@gmail.com> <20161016120510.55c138f0@free-electrons.com> <20161016142837.62bc74ba@free-electrons.com> <816e611d-747b-6e15-5aea-1d83f246c43e@imgtec.com> <1f814abc-0446-88f1-7d98-cb309838b060@imgtec.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net 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... /output/host/usr/bin/mips64-octeon-linux-gnu-ld -G -o $@.t checking shared library extension... so /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" /output/host/usr/bin/mips64-octeon-linux-gnu-ld: failed to merge target specific data of file conftest.a(conftest.o) /output/host/usr/bin/mips64-octeon-linux-gnu-ld: unrecognized option '-all' /output/host/usr/bin/mips64-octeon-linux-gnu-ld: use the --help option for usage information 444 configure:4475: result: /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 > > 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 > >>> 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 > >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: