RFR: Fix stacktraces

[Mikael Vidstedt]

I’m torn about this one, I don’t really like having to patch around things like this, but I don’t have a better suggestion. Question though: do you know if the "faulty implementation” is by-design in musl, or if it’s something that should be fixed?

Cheers,
Mikael

> On Apr 4, 2018, at 7:42 AM, Siebenborn, Axel <axel.siebenborn at sap.com> wrote:
> 
> Hi,
> Currently, stacktraces are not working correctly in portola. The reason is a faulty implementation of dladdr.
> Due to a missing comparison with the size, dladdr claims to have found a symbol for an address, whereas this is just the nearest exported symbol lower to that address. Pointing into a function with a non-exported symbol, returning NULL  for dlinfo.dli_sname and dlinfo.dli_saddr would be the expected behavior.
> 
> The fix is not to use the faulty results of dladdr for dlinfo.dli_sname and dlinfo.dli_saddr and to go the slow path,
> getting the file info using the Decoder class.
> 
> As most symbols in libjvm are not exported, this is the common case anyway.
> 
> I protected the code with #ifndef LIBMUSL. To get this define, I had to change CompileJvm.gmk.
> 
> Webrev:
> http://cr.openjdk.java.net/~asiebenborn/stacktraces/webrev/
> 
> Regards,
> Axel