mailing list of musl libc
 help / color / Atom feed
* another armv7-m exception handling problem
@ 2019-10-21  4:43 Patrick Oppenlander
  2019-10-21  5:04 ` Rich Felker
  2019-10-21 18:09 ` Szabolcs Nagy
  0 siblings, 2 replies; 13+ messages in thread
From: Patrick Oppenlander @ 2019-10-21  4:43 UTC (permalink / raw)
  To: musl

Not sure if this is a musl, gcc or ld bug.

Running gcc-8.3.0 musl 1.1.24 static pie.

Simple test case:

int main()
{
        try {
                throw 1;
        } catch (int d) {
                return d;
        }
        return 0;
}

Expected:
% ./a.out
% echo $?
1

Actual:
% ./a.out
terminate called after throwing an instance of 'int'
terminate called recursively
Aborted (core dumped)

The problem is that get_eit_entry is returning _URC_FAILURE here:

  if (__gnu_Unwind_Find_exidx)
    {
      eitp = (const __EIT_entry *) __gnu_Unwind_Find_exidx (return_address,
                                                            &nrec);
      if (!eitp)
        {
          UCB_PR_ADDR (ucbp) = 0;
          return _URC_FAILURE;        <----- !!!!
        }
    }

Looks like a linker or program load problem to me -- the GOT entry for
__gnu_Unwind_Find_exidx is correctly set to 0, but after program load
it's been offset to some non-zero value. There's an R_ARM_RELATIVE
relocation on the GOT entry.

Not sure where this is going wrong.

Kind regards,

Patrick


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

* Re: another armv7-m exception handling problem
  2019-10-21  4:43 another armv7-m exception handling problem Patrick Oppenlander
@ 2019-10-21  5:04 ` Rich Felker
  2019-10-21  5:20   ` Rich Felker
  2019-10-21 18:09 ` Szabolcs Nagy
  1 sibling, 1 reply; 13+ messages in thread
From: Rich Felker @ 2019-10-21  5:04 UTC (permalink / raw)
  To: musl

On Mon, Oct 21, 2019 at 03:43:40PM +1100, Patrick Oppenlander wrote:
> Not sure if this is a musl, gcc or ld bug.
> 
> Running gcc-8.3.0 musl 1.1.24 static pie.
> 
> Simple test case:
> 
> int main()
> {
>         try {
>                 throw 1;
>         } catch (int d) {
>                 return d;
>         }
>         return 0;
> }
> 
> Expected:
> % ./a.out
> % echo $?
> 1
> 
> Actual:
> % ./a.out
> terminate called after throwing an instance of 'int'
> terminate called recursively
> Aborted (core dumped)
> 
> The problem is that get_eit_entry is returning _URC_FAILURE here:
> 
>   if (__gnu_Unwind_Find_exidx)
>     {
>       eitp = (const __EIT_entry *) __gnu_Unwind_Find_exidx (return_address,
>                                                             &nrec);
>       if (!eitp)
>         {
>           UCB_PR_ADDR (ucbp) = 0;
>           return _URC_FAILURE;        <----- !!!!
>         }
>     }
> 
> Looks like a linker or program load problem to me -- the GOT entry for
> __gnu_Unwind_Find_exidx is correctly set to 0, but after program load
> it's been offset to some non-zero value. There's an R_ARM_RELATIVE
> relocation on the GOT entry.
> 
> Not sure where this is going wrong.

OK, this is almost surely a bug in the tooling -- a weak reference has
to use a GOT slot in PIC since it might be undefined and need to
evaluate to 0, and the GOT slot should not have a relocation on it if
it ends up evaluating to 0. Pretty sure it's ld's fault.

Rich


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

* Re: another armv7-m exception handling problem
  2019-10-21  5:04 ` Rich Felker
@ 2019-10-21  5:20   ` Rich Felker
  2019-10-21  5:34     ` Patrick Oppenlander
  0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2019-10-21  5:20 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Mon, Oct 21, 2019 at 01:04:11AM -0400, Rich Felker wrote:
> On Mon, Oct 21, 2019 at 03:43:40PM +1100, Patrick Oppenlander wrote:
> > Not sure if this is a musl, gcc or ld bug.
> > 
> > Running gcc-8.3.0 musl 1.1.24 static pie.
> > 
> > Simple test case:
> > 
> > int main()
> > {
> >         try {
> >                 throw 1;
> >         } catch (int d) {
> >                 return d;
> >         }
> >         return 0;
> > }
> > 
> > Expected:
> > % ./a.out
> > % echo $?
> > 1
> > 
> > Actual:
> > % ./a.out
> > terminate called after throwing an instance of 'int'
> > terminate called recursively
> > Aborted (core dumped)
> > 
> > The problem is that get_eit_entry is returning _URC_FAILURE here:
> > 
> >   if (__gnu_Unwind_Find_exidx)
> >     {
> >       eitp = (const __EIT_entry *) __gnu_Unwind_Find_exidx (return_address,
> >                                                             &nrec);
> >       if (!eitp)
> >         {
> >           UCB_PR_ADDR (ucbp) = 0;
> >           return _URC_FAILURE;        <----- !!!!
> >         }
> >     }
> > 
> > Looks like a linker or program load problem to me -- the GOT entry for
> > __gnu_Unwind_Find_exidx is correctly set to 0, but after program load
> > it's been offset to some non-zero value. There's an R_ARM_RELATIVE
> > relocation on the GOT entry.
> > 
> > Not sure where this is going wrong.
> 
> OK, this is almost surely a bug in the tooling -- a weak reference has
> to use a GOT slot in PIC since it might be undefined and need to
> evaluate to 0, and the GOT slot should not have a relocation on it if
> it ends up evaluating to 0. Pretty sure it's ld's fault.

I can reproduce it with the attached trivial GNU C program.

Rich

[-- Attachment #2: weakref2.c --]
[-- Type: text/plain, Size: 111 bytes --]

#include <stdio.h>

void foo(void) __attribute__((__weak__));

int main(void)
{
	printf("%p\n", (void*)foo);
}

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

* Re: another armv7-m exception handling problem
  2019-10-21  5:20   ` Rich Felker
@ 2019-10-21  5:34     ` Patrick Oppenlander
  2019-10-21  5:38       ` Rich Felker
  0 siblings, 1 reply; 13+ messages in thread
From: Patrick Oppenlander @ 2019-10-21  5:34 UTC (permalink / raw)
  To: musl

On Mon, Oct 21, 2019 at 4:20 PM Rich Felker <dalias@libc.org> wrote:
>
> On Mon, Oct 21, 2019 at 01:04:11AM -0400, Rich Felker wrote:
> >
> > OK, this is almost surely a bug in the tooling -- a weak reference has
> > to use a GOT slot in PIC since it might be undefined and need to
> > evaluate to 0, and the GOT slot should not have a relocation on it if
> > it ends up evaluating to 0. Pretty sure it's ld's fault.
>

Makes sense. Should I report to the binutils guys?

>
> I can reproduce it with the attached trivial GNU C program.
>

That's certainly easier to debug than my example!

Patrick


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

* Re: another armv7-m exception handling problem
  2019-10-21  5:34     ` Patrick Oppenlander
@ 2019-10-21  5:38       ` Rich Felker
  2019-10-21  5:51         ` Patrick Oppenlander
  0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2019-10-21  5:38 UTC (permalink / raw)
  To: musl

On Mon, Oct 21, 2019 at 04:34:07PM +1100, Patrick Oppenlander wrote:
> On Mon, Oct 21, 2019 at 4:20 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Mon, Oct 21, 2019 at 01:04:11AM -0400, Rich Felker wrote:
> > >
> > > OK, this is almost surely a bug in the tooling -- a weak reference has
> > > to use a GOT slot in PIC since it might be undefined and need to
> > > evaluate to 0, and the GOT slot should not have a relocation on it if
> > > it ends up evaluating to 0. Pretty sure it's ld's fault.
> 
> Makes sense. Should I report to the binutils guys?

I think so, but it would probably be worth determining whether it's
arm-specific or more general first so that the report gets to the
right ppl. I can try it on some other archs tomorrow.

Rich


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

* Re: another armv7-m exception handling problem
  2019-10-21  5:38       ` Rich Felker
@ 2019-10-21  5:51         ` Patrick Oppenlander
  0 siblings, 0 replies; 13+ messages in thread
From: Patrick Oppenlander @ 2019-10-21  5:51 UTC (permalink / raw)
  To: musl

On Mon, Oct 21, 2019 at 4:38 PM Rich Felker <dalias@libc.org> wrote:
>
> On Mon, Oct 21, 2019 at 04:34:07PM +1100, Patrick Oppenlander wrote:
> > On Mon, Oct 21, 2019 at 4:20 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > On Mon, Oct 21, 2019 at 01:04:11AM -0400, Rich Felker wrote:
> > > >
> > > > OK, this is almost surely a bug in the tooling -- a weak reference has
> > > > to use a GOT slot in PIC since it might be undefined and need to
> > > > evaluate to 0, and the GOT slot should not have a relocation on it if
> > > > it ends up evaluating to 0. Pretty sure it's ld's fault.
> >
> > Makes sense. Should I report to the binutils guys?
>
> I think so, but it would probably be worth determining whether it's
> arm-specific or more general first so that the report gets to the
> right ppl. I can try it on some other archs tomorrow.

Here's the ones I have on hand:

% aarch64-linux-musleabi-gcc -static weakref2.c -o aarch64
% arm-linux-musleabi-gcc -static weakref2.c -o arm
% armv7m-linux-musleabi-gcc -static weakref2.c -o armv7m
% x86_64-linux-musl-gcc -static weakref2.c -o x86_64

% ./aarch64
0
% ./arm
0
% ./armv7m
0xfffdb000
% ./x86_64
0

End of day for me too.

Patrick


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

* Re: another armv7-m exception handling problem
  2019-10-21  4:43 another armv7-m exception handling problem Patrick Oppenlander
  2019-10-21  5:04 ` Rich Felker
@ 2019-10-21 18:09 ` Szabolcs Nagy
  2019-10-21 19:03   ` Rich Felker
  2019-10-21 21:17   ` Patrick Oppenlander
  1 sibling, 2 replies; 13+ messages in thread
From: Szabolcs Nagy @ 2019-10-21 18:09 UTC (permalink / raw)
  To: musl

* Patrick Oppenlander <patrick.oppenlander@gmail.com> [2019-10-21 15:43:40 +1100]:
> Not sure if this is a musl, gcc or ld bug.
> 
> Running gcc-8.3.0 musl 1.1.24 static pie.

providing binutils version number is useful if there is
a chance that it's an ld bug.

this seems to be
https://sourceware.org/bugzilla/show_bug.cgi?id=22269

which was supposed to be fixed by
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=95b03e4ad68e7a90f5096b47df595636344b783a

but apperently there are still missing cases.
(it does not help that the ld test for this bug
greps for R_*_NONE dynrelocs but not R_*_RELATIVE
which i is just as bad for undef weak syms in pie)
i added a note to the bug.

if you add __attribute__((visibility("hidden")))
to the example given by Rich then it works, the
bug only affects static pie linking.


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

* Re: another armv7-m exception handling problem
  2019-10-21 18:09 ` Szabolcs Nagy
@ 2019-10-21 19:03   ` Rich Felker
  2019-10-21 19:08     ` Szabolcs Nagy
  2019-10-21 21:17   ` Patrick Oppenlander
  1 sibling, 1 reply; 13+ messages in thread
From: Rich Felker @ 2019-10-21 19:03 UTC (permalink / raw)
  To: musl

On Mon, Oct 21, 2019 at 08:09:56PM +0200, Szabolcs Nagy wrote:
> * Patrick Oppenlander <patrick.oppenlander@gmail.com> [2019-10-21 15:43:40 +1100]:
> > Not sure if this is a musl, gcc or ld bug.
> > 
> > Running gcc-8.3.0 musl 1.1.24 static pie.
> 
> providing binutils version number is useful if there is
> a chance that it's an ld bug.
> 
> this seems to be
> https://sourceware.org/bugzilla/show_bug.cgi?id=22269
> 
> which was supposed to be fixed by
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=95b03e4ad68e7a90f5096b47df595636344b783a
> 
> but apperently there are still missing cases.
> (it does not help that the ld test for this bug
> greps for R_*_NONE dynrelocs but not R_*_RELATIVE
> which i is just as bad for undef weak syms in pie)
> i added a note to the bug.
> 
> if you add __attribute__((visibility("hidden")))
> to the example given by Rich then it works, the
> bug only affects static pie linking.

That's really weird. How does it end up having an outstanding
*relative* relocation when it's not defined locally? I could
understand having a bogus outstanding symbolic one, but relative makes
no sense and suggests ld is doing something very wrong...

Rich


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

* Re: another armv7-m exception handling problem
  2019-10-21 19:03   ` Rich Felker
@ 2019-10-21 19:08     ` Szabolcs Nagy
  2019-10-21 19:29       ` Rich Felker
  0 siblings, 1 reply; 13+ messages in thread
From: Szabolcs Nagy @ 2019-10-21 19:08 UTC (permalink / raw)
  To: musl

* Rich Felker <dalias@libc.org> [2019-10-21 15:03:18 -0400]:
> On Mon, Oct 21, 2019 at 08:09:56PM +0200, Szabolcs Nagy wrote:
> > * Patrick Oppenlander <patrick.oppenlander@gmail.com> [2019-10-21 15:43:40 +1100]:
> > > Not sure if this is a musl, gcc or ld bug.
> > > 
> > > Running gcc-8.3.0 musl 1.1.24 static pie.
> > 
> > providing binutils version number is useful if there is
> > a chance that it's an ld bug.
> > 
> > this seems to be
> > https://sourceware.org/bugzilla/show_bug.cgi?id=22269
> > 
> > which was supposed to be fixed by
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=95b03e4ad68e7a90f5096b47df595636344b783a
> > 
> > but apperently there are still missing cases.
> > (it does not help that the ld test for this bug
> > greps for R_*_NONE dynrelocs but not R_*_RELATIVE
> > which i is just as bad for undef weak syms in pie)
> > i added a note to the bug.
> > 
> > if you add __attribute__((visibility("hidden")))
> > to the example given by Rich then it works, the
> > bug only affects static pie linking.
> 
> That's really weird. How does it end up having an outstanding
> *relative* relocation when it's not defined locally? I could
> understand having a bogus outstanding symbolic one, but relative makes
> no sense and suggests ld is doing something very wrong...

i'd guess it creates a relative reloc for every
got entry that stores some symbol's address
which is known to be local, which makes sense,
except for undefined weak symbols which should
have fixed 0 address.

and i'd guess there is some logic that special
cases local undef weak in pic so hidden works,
and that check should be extended to cover the
static pie case.


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

* Re: another armv7-m exception handling problem
  2019-10-21 19:08     ` Szabolcs Nagy
@ 2019-10-21 19:29       ` Rich Felker
  2020-01-10 10:22         ` Szabolcs Nagy
  0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2019-10-21 19:29 UTC (permalink / raw)
  To: musl

On Mon, Oct 21, 2019 at 09:08:57PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2019-10-21 15:03:18 -0400]:
> > On Mon, Oct 21, 2019 at 08:09:56PM +0200, Szabolcs Nagy wrote:
> > > * Patrick Oppenlander <patrick.oppenlander@gmail.com> [2019-10-21 15:43:40 +1100]:
> > > > Not sure if this is a musl, gcc or ld bug.
> > > > 
> > > > Running gcc-8.3.0 musl 1.1.24 static pie.
> > > 
> > > providing binutils version number is useful if there is
> > > a chance that it's an ld bug.
> > > 
> > > this seems to be
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=22269
> > > 
> > > which was supposed to be fixed by
> > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=95b03e4ad68e7a90f5096b47df595636344b783a
> > > 
> > > but apperently there are still missing cases.
> > > (it does not help that the ld test for this bug
> > > greps for R_*_NONE dynrelocs but not R_*_RELATIVE
> > > which i is just as bad for undef weak syms in pie)
> > > i added a note to the bug.
> > > 
> > > if you add __attribute__((visibility("hidden")))
> > > to the example given by Rich then it works, the
> > > bug only affects static pie linking.
> > 
> > That's really weird. How does it end up having an outstanding
> > *relative* relocation when it's not defined locally? I could
> > understand having a bogus outstanding symbolic one, but relative makes
> > no sense and suggests ld is doing something very wrong...
> 
> i'd guess it creates a relative reloc for every
> got entry that stores some symbol's address
> which is known to be local, which makes sense,
> except for undefined weak symbols which should
> have fixed 0 address.
> 
> and i'd guess there is some logic that special
> cases local undef weak in pic so hidden works,
> and that check should be extended to cover the
> static pie case.

In 2.33.1, the offending code (creating the bad relative relocation)
is at line 11637. It's possible some earlier code path leading to it
is wrong, around line 11515 or so, but I think there just needs to be
an extra else path before this one that covers undefined/undefweak.

Rich


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

* Re: another armv7-m exception handling problem
  2019-10-21 18:09 ` Szabolcs Nagy
  2019-10-21 19:03   ` Rich Felker
@ 2019-10-21 21:17   ` Patrick Oppenlander
  1 sibling, 0 replies; 13+ messages in thread
From: Patrick Oppenlander @ 2019-10-21 21:17 UTC (permalink / raw)
  To: Szabolcs Nagy; +Cc: musl

On Tue, Oct 22, 2019 at 5:10 AM Szabolcs Nagy <nsz@port70.net> wrote:
>
> * Patrick Oppenlander <patrick.oppenlander@gmail.com> [2019-10-21 15:43:40 +1100]:
> > Not sure if this is a musl, gcc or ld bug.
> >
> > Running gcc-8.3.0 musl 1.1.24 static pie.
>
> providing binutils version number is useful if there is
> a chance that it's an ld bug.
>

Sorry.

binutils 2.32 including musl-cross-make patches as at commit
02be46d639e716adcf7a01bd78a0d32bfb320ab7 (add patches fixing ld bug
linking arm tlsdesc relocs on 64-bit host)

Patrick


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

* Re: another armv7-m exception handling problem
  2019-10-21 19:29       ` Rich Felker
@ 2020-01-10 10:22         ` Szabolcs Nagy
  2020-01-11  6:20           ` Patrick Oppenlander
  0 siblings, 1 reply; 13+ messages in thread
From: Szabolcs Nagy @ 2020-01-10 10:22 UTC (permalink / raw)
  To: musl; +Cc: Patrick Oppenlander

* Rich Felker <dalias@libc.org> [2019-10-21 15:29:37 -0400]:
> On Mon, Oct 21, 2019 at 09:08:57PM +0200, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2019-10-21 15:03:18 -0400]:
> > > On Mon, Oct 21, 2019 at 08:09:56PM +0200, Szabolcs Nagy wrote:
> > > > * Patrick Oppenlander <patrick.oppenlander@gmail.com> [2019-10-21 15:43:40 +1100]:
> > > > > Not sure if this is a musl, gcc or ld bug.
> > > > > 
> > > > > Running gcc-8.3.0 musl 1.1.24 static pie.
> > > > 
> > > > providing binutils version number is useful if there is
> > > > a chance that it's an ld bug.
> > > > 
> > > > this seems to be
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=22269
> > > > 
> > > > which was supposed to be fixed by
> > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=95b03e4ad68e7a90f5096b47df595636344b783a
> > > > 
> > > > but apperently there are still missing cases.
> > > > (it does not help that the ld test for this bug
> > > > greps for R_*_NONE dynrelocs but not R_*_RELATIVE
> > > > which i is just as bad for undef weak syms in pie)
> > > > i added a note to the bug.
> > > > 
> > > > if you add __attribute__((visibility("hidden")))
> > > > to the example given by Rich then it works, the
> > > > bug only affects static pie linking.
> > > 
> > > That's really weird. How does it end up having an outstanding
> > > *relative* relocation when it's not defined locally? I could
> > > understand having a bogus outstanding symbolic one, but relative makes
> > > no sense and suggests ld is doing something very wrong...
> > 
> > i'd guess it creates a relative reloc for every
> > got entry that stores some symbol's address
> > which is known to be local, which makes sense,
> > except for undefined weak symbols which should
> > have fixed 0 address.
> > 
> > and i'd guess there is some logic that special
> > cases local undef weak in pic so hidden works,
> > and that check should be extended to cover the
> > static pie case.
> 
> In 2.33.1, the offending code (creating the bad relative relocation)
> is at line 11637. It's possible some earlier code path leading to it
> is wrong, around line 11515 or so, but I think there just needs to be
> an extra else path before this one that covers undefined/undefweak.

fyi i have a patch now, hopefully will be included into binutils 2.34
https://sourceware.org/ml/binutils/2020-01/msg00096.html


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

* Re: another armv7-m exception handling problem
  2020-01-10 10:22         ` Szabolcs Nagy
@ 2020-01-11  6:20           ` Patrick Oppenlander
  0 siblings, 0 replies; 13+ messages in thread
From: Patrick Oppenlander @ 2020-01-11  6:20 UTC (permalink / raw)
  To: musl

On Fri, Jan 10, 2020 at 9:22 PM Szabolcs Nagy <nsz@port70.net> wrote:
>
> fyi i have a patch now, hopefully will be included into binutils 2.34
> https://sourceware.org/ml/binutils/2020-01/msg00096.html
>

That's great news, thank you.

Could the patch be included in mcm in the mean time?

Patrick


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

end of thread, back to index

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-21  4:43 another armv7-m exception handling problem Patrick Oppenlander
2019-10-21  5:04 ` Rich Felker
2019-10-21  5:20   ` Rich Felker
2019-10-21  5:34     ` Patrick Oppenlander
2019-10-21  5:38       ` Rich Felker
2019-10-21  5:51         ` Patrick Oppenlander
2019-10-21 18:09 ` Szabolcs Nagy
2019-10-21 19:03   ` Rich Felker
2019-10-21 19:08     ` Szabolcs Nagy
2019-10-21 19:29       ` Rich Felker
2020-01-10 10:22         ` Szabolcs Nagy
2020-01-11  6:20           ` Patrick Oppenlander
2019-10-21 21:17   ` 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