[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Oct 2019 15:29:37 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: another armv7-m exception handling problem
On Mon, Oct 21, 2019 at 09:08:57PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.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@...il.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
