mailing list of musl libc
 help / color / Atom feed
* [musl] armv7-m musl 1.2.0 toolchain crash
@ 2020-03-16  5:41 Patrick Oppenlander
  2020-03-16 17:54 ` Rich Felker
  2020-03-18 19:10 ` Szabolcs Nagy
  0 siblings, 2 replies; 5+ messages in thread
From: Patrick Oppenlander @ 2020-03-16  5:41 UTC (permalink / raw)
  To: musl

After the update to musl 1.2.0 (1.1.24 was fine) ld crashes when
trying to link a C++ executable. C executables successfully link. The
toolchain was built as at commit
5086175f29021e3bebb7d9f5d83c4a796d96ebbd of musl-cross-make with the
following configuration:

TARGET = armv7m-linux-musleabihf
GCC_CONFIG += --with-cpu=cortex-m7  # easier than arch/fpu/tune
GCC_CONFIG += --enable-languages=c,c++
GCC_CONFIG += --disable-libquadmath --disable-decimal-float
GCC_CONFIG += --enable-default-pie
GCC_CONFIG += --enable-cxx-flags="-ffunction-sections"
MUSL_CONFIG += --enable-debug
COMMON_CONFIG += CFLAGS="-g0 -Os" CXXFLAGS="-g0 -Os"
COMMON_CONFIG += --disable-nls
COMMON_CONFIG += --with-debug-prefix-map=\$(CURDIR)=

Host compiler is arch linux gcc 9.3.0-1.

This results in a toolchain which does the following:
% cat test.c
int main() { return 0; }
% armv7m-linux-musleabi-gcc test.c
% armv7m-linux-musleabi-g++ test.c
collect2: fatal error: ld terminated with signal 11 [Segmentation
fault], core dumped
compilation terminated.

The crash is a null pointer dereference in ld here (sym_hashes is 0):

(gdb) bt
#0  cmse_scan (input_bfd=0x555555e3a110, htab=0x55555578a260,
out_attr=0x5555557885c0, sym_hashes=0x0,
cmse_stub_created=0x7fffffffd4c8)
    at ../../src_binutils/bfd/elf32-arm.c:6016
#1  0x00005555555de1e7 in elf32_arm_size_stubs
(output_bfd=0x555555788100, stub_bfd=0x55555579c8c0,
info=0x55555574c4a0 <link_info>, group_size=1,
    add_stub_section=0x5555555a9ecd <elf32_arm_add_stub_section>,
layout_sections_again=0x5555555aa049 <gldarm_layout_sections_again>)
    at ../../src_binutils/bfd/elf32-arm.c:6542
#2  0x00005555555aa43b in gldarmelf_linux_eabi_after_allocation () at
earmelf_linux_eabi.c:481
#3  0x00005555555a2351 in ldemul_after_allocation () at
../../src_binutils/ld/ldemul.c:76
#4  0x0000555555597a6d in lang_process () at ../../src_binutils/ld/ldlang.c:7693
#5  0x000055555559bce5 in main (argc=35, argv=0x7fffffffd8b8) at
../../src_binutils/ld/ldmain.c:441

Looks like a change in musl have exposed an ld bug.

Happy to provide more debugging if it helps.

Kind regards,

Patrick

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] armv7-m musl 1.2.0 toolchain crash
  2020-03-16  5:41 [musl] armv7-m musl 1.2.0 toolchain crash Patrick Oppenlander
@ 2020-03-16 17:54 ` Rich Felker
  2020-03-17  0:40   ` Patrick Oppenlander
  2020-03-18 19:10 ` Szabolcs Nagy
  1 sibling, 1 reply; 5+ messages in thread
From: Rich Felker @ 2020-03-16 17:54 UTC (permalink / raw)
  To: musl

On Mon, Mar 16, 2020 at 04:41:17PM +1100, Patrick Oppenlander wrote:
> After the update to musl 1.2.0 (1.1.24 was fine) ld crashes when
> trying to link a C++ executable. C executables successfully link. The
> toolchain was built as at commit
> 5086175f29021e3bebb7d9f5d83c4a796d96ebbd of musl-cross-make with the
> following configuration:
> 
> TARGET = armv7m-linux-musleabihf
> GCC_CONFIG += --with-cpu=cortex-m7  # easier than arch/fpu/tune
> GCC_CONFIG += --enable-languages=c,c++
> GCC_CONFIG += --disable-libquadmath --disable-decimal-float
> GCC_CONFIG += --enable-default-pie
> GCC_CONFIG += --enable-cxx-flags="-ffunction-sections"
> MUSL_CONFIG += --enable-debug
> COMMON_CONFIG += CFLAGS="-g0 -Os" CXXFLAGS="-g0 -Os"
> COMMON_CONFIG += --disable-nls
> COMMON_CONFIG += --with-debug-prefix-map=\$(CURDIR)=
> 
> Host compiler is arch linux gcc 9.3.0-1.
> 
> This results in a toolchain which does the following:
> % cat test.c
> int main() { return 0; }
> % armv7m-linux-musleabi-gcc test.c
> % armv7m-linux-musleabi-g++ test.c
> collect2: fatal error: ld terminated with signal 11 [Segmentation
> fault], core dumped
> compilation terminated.
> 
> The crash is a null pointer dereference in ld here (sym_hashes is 0):
> 
> (gdb) bt
> #0  cmse_scan (input_bfd=0x555555e3a110, htab=0x55555578a260,
> out_attr=0x5555557885c0, sym_hashes=0x0,
> cmse_stub_created=0x7fffffffd4c8)
>     at ../../src_binutils/bfd/elf32-arm.c:6016
> #1  0x00005555555de1e7 in elf32_arm_size_stubs
> (output_bfd=0x555555788100, stub_bfd=0x55555579c8c0,
> info=0x55555574c4a0 <link_info>, group_size=1,
>     add_stub_section=0x5555555a9ecd <elf32_arm_add_stub_section>,
> layout_sections_again=0x5555555aa049 <gldarm_layout_sections_again>)
>     at ../../src_binutils/bfd/elf32-arm.c:6542
> #2  0x00005555555aa43b in gldarmelf_linux_eabi_after_allocation () at
> earmelf_linux_eabi.c:481
> #3  0x00005555555a2351 in ldemul_after_allocation () at
> .../../src_binutils/ld/ldemul.c:76
> #4  0x0000555555597a6d in lang_process () at ../../src_binutils/ld/ldlang.c:7693
> #5  0x000055555559bce5 in main (argc=35, argv=0x7fffffffd8b8) at
> .../../src_binutils/ld/ldmain.c:441
> 
> Looks like a change in musl have exposed an ld bug.

Can you clarify if the change is that the toolchain is built against
musl 1.2.0 and now malfunctioning, or trying to link to musl 1.2.0 and
now malfunctioning? Those are very different and it's not clear which.

Rich

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] armv7-m musl 1.2.0 toolchain crash
  2020-03-16 17:54 ` Rich Felker
@ 2020-03-17  0:40   ` Patrick Oppenlander
  0 siblings, 0 replies; 5+ messages in thread
From: Patrick Oppenlander @ 2020-03-17  0:40 UTC (permalink / raw)
  To: musl

On Tue, Mar 17, 2020 at 4:54 AM Rich Felker <dalias@libc.org> wrote:
>
> Can you clarify if the change is that the toolchain is built against
> musl 1.2.0 and now malfunctioning, or trying to link to musl 1.2.0 and
> now malfunctioning? Those are very different and it's not clear which.
>

Sorry, my previous email was no where near clear enough. I'll try to
do better this time :)

All of my toolchains are built against glibc as I build them with the
default host compiler on my Arch Linux system.

I typed out a huge email detailing dozens of tests which I performed,
but it's all irrelevant and boils down to the following:

gcc   / binutils / musl  / C++ link
7.4.0 / 2.27     / 1.2.0 / works
7.4.0 / 2.32     / 1.2.0 / fails
7.4.0 / 2.33.1   / 1.2.0 / fails
7.4.0 / 2.34     / 1.2.0 / works (binutils-2.34 no mcm patches)
9.2.0 / 2.34     / 1.2.0 / works
9.3.0 / 2.34     / 1.2.0 / works (using mcm gcc 9.2.0 patches)

So it looks to me like there was a regression in binutils introduced
after version 2.27 and fixed in 2.34.

BTW, the gcc 9.2.0 patches apply with some fuzz to 9.3.0 with the
exception of 0017-pr93402.diff which is upstream. I'll do further
testing over the next week or two on the gcc 9.3.0 arm & armv7m
targets with binutils 2.34 and musl 1.2.0.

Hope that helps,

Patrick

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] armv7-m musl 1.2.0 toolchain crash
  2020-03-16  5:41 [musl] armv7-m musl 1.2.0 toolchain crash Patrick Oppenlander
  2020-03-16 17:54 ` Rich Felker
@ 2020-03-18 19:10 ` Szabolcs Nagy
  2020-03-18 22:43   ` Patrick Oppenlander
  1 sibling, 1 reply; 5+ messages in thread
From: Szabolcs Nagy @ 2020-03-18 19:10 UTC (permalink / raw)
  To: musl; +Cc: Patrick Oppenlander

* Patrick Oppenlander <patrick.oppenlander@gmail.com> [2020-03-16 16:41:17 +1100]:
> After the update to musl 1.2.0 (1.1.24 was fine) ld crashes when
> trying to link a C++ executable. C executables successfully link. The
> toolchain was built as at commit
> 5086175f29021e3bebb7d9f5d83c4a796d96ebbd of musl-cross-make with the
> following configuration:
> 
> TARGET = armv7m-linux-musleabihf
> GCC_CONFIG += --with-cpu=cortex-m7  # easier than arch/fpu/tune
> GCC_CONFIG += --enable-languages=c,c++
> GCC_CONFIG += --disable-libquadmath --disable-decimal-float
> GCC_CONFIG += --enable-default-pie
> GCC_CONFIG += --enable-cxx-flags="-ffunction-sections"
> MUSL_CONFIG += --enable-debug
> COMMON_CONFIG += CFLAGS="-g0 -Os" CXXFLAGS="-g0 -Os"
> COMMON_CONFIG += --disable-nls
> COMMON_CONFIG += --with-debug-prefix-map=\$(CURDIR)=
> 
> Host compiler is arch linux gcc 9.3.0-1.
> 
> This results in a toolchain which does the following:
> % cat test.c
> int main() { return 0; }
> % armv7m-linux-musleabi-gcc test.c
> % armv7m-linux-musleabi-g++ test.c
> collect2: fatal error: ld terminated with signal 11 [Segmentation
> fault], core dumped
> compilation terminated.
> 
> The crash is a null pointer dereference in ld here (sym_hashes is 0):
> 
> (gdb) bt
> #0  cmse_scan (input_bfd=0x555555e3a110, htab=0x55555578a260,
> out_attr=0x5555557885c0, sym_hashes=0x0,
> cmse_stub_created=0x7fffffffd4c8)
>     at ../../src_binutils/bfd/elf32-arm.c:6016


this is likely fixed by this binutils commit:

commit 73d5efd7e13ebd8fe87278224bc2ae777af3de52
Author:     Alan Modra <amodra@gmail.com>
AuthorDate: 2019-11-21 08:57:00 +1030
Commit:     Alan Modra <amodra@gmail.com>
CommitDate: 2019-11-21 21:08:30 +1030

    ARM cmse_scan segfault
    
    This code in elf_link_add_object_symbols:
    
          ret = elf_add_dt_needed_tag (abfd, info, soname, add_needed);
          if (ret < 0)
            goto error_return;
    
          /* If we have already included this dynamic object in the
             link, just ignore it.  There is no reason to include a
             particular dynamic object more than once.  */
          if (ret > 0)
            return TRUE;
    
    prevents a shared library from being loaded twice by ensuring that any
    library soname doesn't match the soname of one already loaded.  This
    happens before sym_hashes are allocated, which leaves sym_hashes NULL.
    
    cmse_scan looks at library symbols, and when attempting to look up a
    global symbol will segfault if sym_hashes is zero.
    
            * elf32-arm.c (elf32_arm_size_stubs): Exclude dynamic library
            BFDs that have not been loaded.


which was not backported to earlier release branches so only in 2.34.
(old binutils had no cmse support so that should work too)


> #1  0x00005555555de1e7 in elf32_arm_size_stubs
> (output_bfd=0x555555788100, stub_bfd=0x55555579c8c0,
> info=0x55555574c4a0 <link_info>, group_size=1,
>     add_stub_section=0x5555555a9ecd <elf32_arm_add_stub_section>,
> layout_sections_again=0x5555555aa049 <gldarm_layout_sections_again>)
>     at ../../src_binutils/bfd/elf32-arm.c:6542
> #2  0x00005555555aa43b in gldarmelf_linux_eabi_after_allocation () at
> earmelf_linux_eabi.c:481
> #3  0x00005555555a2351 in ldemul_after_allocation () at
> ../../src_binutils/ld/ldemul.c:76
> #4  0x0000555555597a6d in lang_process () at ../../src_binutils/ld/ldlang.c:7693
> #5  0x000055555559bce5 in main (argc=35, argv=0x7fffffffd8b8) at
> ../../src_binutils/ld/ldmain.c:441
> 
> Looks like a change in musl have exposed an ld bug.
> 
> Happy to provide more debugging if it helps.
> 
> Kind regards,
> 
> Patrick

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [musl] armv7-m musl 1.2.0 toolchain crash
  2020-03-18 19:10 ` Szabolcs Nagy
@ 2020-03-18 22:43   ` Patrick Oppenlander
  0 siblings, 0 replies; 5+ messages in thread
From: Patrick Oppenlander @ 2020-03-18 22:43 UTC (permalink / raw)
  To: musl

On Thu, Mar 19, 2020 at 6:10 AM Szabolcs Nagy <nsz@port70.net> wrote:
>
> * Patrick Oppenlander <patrick.oppenlander@gmail.com> [2020-03-16 16:41:17 +1100]:
> > After the update to musl 1.2.0 (1.1.24 was fine) ld crashes when
> > trying to link a C++ executable. C executables successfully link. The
> > toolchain was built as at commit
> > 5086175f29021e3bebb7d9f5d83c4a796d96ebbd of musl-cross-make with the
> > following configuration:
> >
> > TARGET = armv7m-linux-musleabihf
> > GCC_CONFIG += --with-cpu=cortex-m7  # easier than arch/fpu/tune
> > GCC_CONFIG += --enable-languages=c,c++
> > GCC_CONFIG += --disable-libquadmath --disable-decimal-float
> > GCC_CONFIG += --enable-default-pie
> > GCC_CONFIG += --enable-cxx-flags="-ffunction-sections"
> > MUSL_CONFIG += --enable-debug
> > COMMON_CONFIG += CFLAGS="-g0 -Os" CXXFLAGS="-g0 -Os"
> > COMMON_CONFIG += --disable-nls
> > COMMON_CONFIG += --with-debug-prefix-map=\$(CURDIR)=
> >
> > Host compiler is arch linux gcc 9.3.0-1.
> >
> > This results in a toolchain which does the following:
> > % cat test.c
> > int main() { return 0; }
> > % armv7m-linux-musleabi-gcc test.c
> > % armv7m-linux-musleabi-g++ test.c
> > collect2: fatal error: ld terminated with signal 11 [Segmentation
> > fault], core dumped
> > compilation terminated.
> >
> > The crash is a null pointer dereference in ld here (sym_hashes is 0):
> >
> > (gdb) bt
> > #0  cmse_scan (input_bfd=0x555555e3a110, htab=0x55555578a260,
> > out_attr=0x5555557885c0, sym_hashes=0x0,
> > cmse_stub_created=0x7fffffffd4c8)
> >     at ../../src_binutils/bfd/elf32-arm.c:6016
>
>
> this is likely fixed by this binutils commit:
>
> commit 73d5efd7e13ebd8fe87278224bc2ae777af3de52
> Author:     Alan Modra <amodra@gmail.com>
> AuthorDate: 2019-11-21 08:57:00 +1030
> Commit:     Alan Modra <amodra@gmail.com>
> CommitDate: 2019-11-21 21:08:30 +1030
>
>     ARM cmse_scan segfault
>

Thanks for looking into it.

Patrick

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-16  5:41 [musl] armv7-m musl 1.2.0 toolchain crash Patrick Oppenlander
2020-03-16 17:54 ` Rich Felker
2020-03-17  0:40   ` Patrick Oppenlander
2020-03-18 19:10 ` Szabolcs Nagy
2020-03-18 22:43   ` Patrick Oppenlander

mailing list of musl libc

Archives are clonable: git clone --mirror http://inbox.vuxu.org/musl

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git