This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM Linux EABI: unwinding through a segfault handler


On 4 October 2015 at 10:50, mads_bn <madsbn@mail.dk> wrote:
> Can somebody try if e.g. backtrace_symbols () will show where the offending
> code was called from?

Included a backtrace test, pushed to github.

./test(_Z9backtracev+0xb)[0x10f28]
./test(_Z17backtrace_handleri+0x5)[0x10f4a]     <---- signal handler
./test[0x112b6]     <---- __default_rt_sa_restorer_v2 (my version)
./test(_Z9test_segvf+0xd)[0x10f6e]      <--- NULL dereference
...

It's a bit awkward that it can only show dynamic symbols and doesn't
demangle them. There are probably better backtrace-generators out
there.

An unpleasant surprise was that installing an std::terminate_handler
made an uncaught exception *less* informative rather than more:

./test(_Z9backtracev+0xb)[0x10f28]
./test(_Z15abort_backtracev+0x5)[0x10f3e]
/lib/libstdc++.so.6(+0x6f1c8)[0xf67121c8]
qemu: uncaught target signal 6 (Aborted) - core dumped

versus

terminate called after throwing an instance of 'IntendedUncaughtException'
qemu: uncaught target signal 6 (Aborted) - core dumped

I thought the whole idea behind two-phase unwinding was to leave the
stack intact for inspection on an uncaught exception. Oh well...

> I don't have access to such an ARM setup currently

As shown above, an ARM setup is one "apt-get install qemu-user" away ;-)

Matthijs


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]