This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java 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: Fix backtrace for interpreted code


Ranjit Mathew writes:
 > 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.

Right.

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

The unwinder library in unwind-compat.c doesn't do anything useful,
which is what I mean by "disabled".

 > > 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?

Yes.

 > If yes, under what conditions?

Always.  g++ always sets flag_unit_at_a_time, so functions are not
output in the order they're declared.

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

I'll put in a comment.

Andrew.


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