From: Jan Heylen <heyleke@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper
Date: Sun, 16 Oct 2016 19:27:48 +0200 [thread overview]
Message-ID: <CAGszK3gfxms0WsgKByZvrz8KDG+PPFS_7_PQicu2fMCtm72E3w@mail.gmail.com> (raw)
In-Reply-To: <b9d595a6-5ac5-7692-742b-03596ca68943@imgtec.com>
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
> >>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161016/48ed5b5d/attachment.html>
next prev parent reply other threads:[~2016-10-16 17:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 19:45 [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 2/4] toolchain: add option to specify ld emulation Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 3/4] toolchain: add TARGET_LDFLAGS to toolchain-wrapper Jan Heylen
2016-04-05 19:45 ` [Buildroot] [PATCH v2 4/4] arch: define appropriate ld emulation values for the MIPS architecture Jan Heylen
2016-10-16 10:05 ` [Buildroot] [PATCH v2 1/4] toolchain: wrap 'ld' with toolchain-wrapper Thomas Petazzoni
2016-10-16 11:36 ` Jan Heylen
2016-10-16 12:28 ` Thomas Petazzoni
2016-10-16 12:38 ` Vicente Olivert Riera
2016-10-16 15:00 ` Jan Heylen
2016-10-16 15:15 ` Vicente Olivert Riera
2016-10-16 15:19 ` Jan Heylen
2016-10-16 15:33 ` Vicente Olivert Riera
2016-10-16 17:27 ` Jan Heylen [this message]
2016-10-24 6:00 ` Jan Heylen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGszK3gfxms0WsgKByZvrz8KDG+PPFS_7_PQicu2fMCtm72E3w@mail.gmail.com \
--to=heyleke@gmail.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.