Bug 9270 - Stepping over longjmp presumably broken for glibc
Summary: Stepping over longjmp presumably broken for glibc
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: breakpoints (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Sergio Durigan Junior
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-31 19:38 UTC by Paul Eggert
Modified: 2012-09-15 06:10 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Eggert 2006-08-31 19:38:01 UTC 
[Converted from Gnats 2165]

This problem report follows up on the thread
"Stepping over longjmp presumably broken for glibc"
<http://sources.redhat.com/ml/gdb/2005-12/msg00177.html>
that was on the GDB mailing list late last year.

I was wondering whether Daniel Jacobowitz's suggestion to
single-step through longjmp needed any help from glibc to
become practical, or whether GDB can do it on its own
without any changes from glibc.  If the former, what sort of
help would be useful?  For example, does GDB need help to
find out where the longjmp machine code begins and ends?

Release:
CVS

Environment:
glibc
Comment 1 Tom Tromey 2011-07-29 20:03:07 UTC 
For Fedora we solved this by putting systemtap probes
at the appropriate spots in the glibc longjmp code.
Then we modified gdb to use these when available.
See the branch roland/systemtap in glibc for the probes.
See the branch archer-sergiodj-stap-patch-split in archer.git
for the gdb side.
Comment 2 Jan Kratochvil 2012-09-15 06:10:38 UTC 
This is fixed now.

glibc/
	commit 8422c9a560e6e3c854739c8a13ecb1c6714f930f
	Author: Roland McGrath <roland@hack.frob.com>
	Date:   Fri May 25 13:31:57 2012 -0700
	    Add systemtap static probe points in setjmp/longjmp on x86.
gdb/
	commit 014135139c612fe1fbe6f11d2350f72325a66f7c
	Author: sergiodj <sergiodj>
	Date:   Fri Apr 27 20:48:52 2012 +0000
	    2012-04-27  Sergio Durigan Junior  <sergiodj@redhat.com>
			Tom Tromey  <tromey@redhat.com>