RFR: Fix stacktraces

[Siebenborn, Axel]

Hi Mikael,

I sent a patch to the musl list, but there was no reaction until now.
http://www.openwall.com/lists/musl/2018/04/03/2

I don't like the workaround using the MUSL macro.
As I understand the code, the part I don't use for musl, is a fast path, that is not really needed.
And there are not many exported symbols in the libjvm, where this path is executed.
I think, it wouldn't hurt to remove it for all linuxes.

Regards,
Axel


> -----Original Message-----
> From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com]
> Sent: Montag, 9. April 2018 19:37
> To: Siebenborn, Axel <axel.siebenborn at sap.com>
> Cc: portola-dev at openjdk.java.net
> Subject: Re: RFR: Fix stacktraces
> 
> 
> 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