[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEg67GnC-DMqkMOUs+3uEnetac_L52ehpALxq8oyS_9kg9RJtw@mail.gmail.com>
Date: Mon, 21 Oct 2019 15:43:40 +1100
From: Patrick Oppenlander <patrick.oppenlander@...il.com>
To: musl@...ts.openwall.com
Subject: another armv7-m exception handling problem
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
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.
