This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: PATCH: Turn on -fomit-frame-pointer by default for 32bit Linux/x86


H.J. Lu <hjl.tools <at> gmail.com> writes:
> On Wed, Aug 4, 2010 at 10:06 AM, Andrew Haley <aph <at> redhat.com> wrote:
> > On 08/04/2010 06:05 PM, Andrew Haley wrote:
> > And for systemtap and java:
> >
> > "systemtap uses .eh_frame/.debug_frame unwind info to get backtraces
> > (both kernel and user space), so that should be fine with/without
> > framepointers (but kind of relies on -fasynchronous-unwind-tables, which
> > is the default on fedora/rhel). The jstack support for hotspot relies on
> > frame_pointers being generated by the JITs (which isn't always true, but
> > it can often recover when it finds a frame that doesn't have one)."
> >
> 
> Does jstack work on Linux/x86-64?

Yes. The systemtap jstack support relies on the code generated by the java
hotspot code generator. It walks "java frames". So it doesn't matter (much) what
gcc generated itself. In theory it would break down if a non-java frame sneaks
in without an explicit frame-pointer (like JNI code). gcc on x86_64 doesn't
generate them, but we haven't heard much complains (jstack tries to recover and
guess the next stack frame). If there are complaints it is too unreliable jstack
might be extended to find/use the (java) stack frame data from the hotspot
runtime (which already has to deal with unwinding through mixed java/native code
without frame-pointers. Or it could try reusing the systemtap support for
walking the user stack through CFIs for those "native" frames.

Cheers,

Mark


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