Re: Fix backtrace for interpreted code

[Ranjit Mathew <rmathew at gmail dot com>]

On Thu, 14 Oct 2004 11:50:24 +0100, Andrew Haley <aph@redhat.com> wrote:
> Ranjit Mathew writes:
>  > Andrew Haley wrote:
>  > >
>  > > There's no truly portable way to do something like this, but with a
>  > > little help from the unwinder library we can do it.  This won't work
>  > > without the unwinder, but as far as I'm aware
>  > > _Unwind_FindEnclosingFunction should work on all targets.
>  > >
>  > > Is this true even of mingw and Cygwin?  Anyone who knows, please let
>  > > me know.
>  >
>  > _Unwind_FindEnclosingFunction in unwind-sjlj.c always
>  > returns NULL, so I would assume that it would not work
>  > as expected on MinGW and Cygwin if GCC for these targets
>  > is built to use SJLJ EH instead of DWARF-2 EH.
> 
> I see.  So, if you use SJLJ EH on these targets, it disables the
> unwinder library as well?

I'm not sure what exactly you mean by "unwinder 
library", but these functions seem to be provided
by libgcc, which pulls in the actual definition from
either unwind-dw2.c or unwind-sjlj.c or unwind-compat.c
as needed.

So in that sense, I don't think it is disabled for
SJLJ targets, but certainly the 
_Unwind_FindEnclosingFunction bit is broken
for them.


> In any case, I don't think this patch will break such systems, as
> they're already broken.

Sorry, for being a bit naive, but why is the current
mechanism "truly bogus"? Is it because the assumption
that _Jv_StartOfInterpreter, _Jv_InterpMethod::run
and _Jv_EndOfInterpreter will be contiguosly laid
out in the text segment (and in that order) is invalid?
If yes, under what conditions? If not, what else?

I also did not totally grok the setting of
_Jv_EndOfInterpreter in your patch. Can you please
explain a bit?

Thanks,
Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT gmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/