[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Oct 2019 21:08:57 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: another armv7-m exception handling problem
* 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.
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.
