Lassi Tuura <[email protected]> writes: > Hi, > >> Hmm. Looking at it, it might seem like libpthread is lacking some >> symbols, creating problems. > > Symbols don't affect unwinding, as far as I know.
Yeah, that was another thing I was wondering about... Can I in some way use strip or other tools to remove debug symbols while keeping unwind info alive? It currently does not work at all if I don't have my oversized libc and libpthread with full debug info in there. >> One thing, though: For release software, we'd prefer to ship >> without debugging symbols. I can accept that that means we have >> worse backtraces, but it's not particularly handy that the >> unwinding segfaults. Is this hard to avoid? > > See my other reply, you are dropping into frame-chain (= fallback) > walk code. It can be exceedingly hard to get that to work > reliably. On x86_64 we added this to be very careful when in that > piece of code: > > /* We could get here because of missing/bad unwind information. > Validate all addresses before dereferencing. */ > c->validate = 1; > > ARM code doesn't do that, though I don't know if ARM has validating > memory access calls in the first place. You might want to compare > the code a bit. I don't know either. Will have to research some. I'll have a look. -- Henrik Grindal Bakken <[email protected]> PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
