This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
breakpoints/1499: GDB's `longjmp' facility doesn't work with shared libs
- From: kettenis at gnu dot org
- To: gdb-gnats at sources dot redhat dot com
- Date: 4 Jan 2004 15:54:17 -0000
- Subject: breakpoints/1499: GDB's `longjmp' facility doesn't work with shared libs
- Reply-to: kettenis at gnu dot org
>Number: 1499
>Category: breakpoints
>Synopsis: GDB's `longjmp' facility doesn't work with shared libs
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Jan 04 15:58:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: Mark Kettenis <kettenis@gnu.org>
>Release: unknown-1.0
>Organization:
>Environment:
i386-unknown-freebsd4.7
>Description:
Stepping through longjmp doesn't work for dynamically linked binaries. Typically, if you say next on a longjmp call, the inferior will run until exit. With statically linked binaries things work just fine; you end up on the first line after the corresponding setjmp.
The problem is that longjmp is in the shared libc. When setting its longjmp breakpoints, GDB disables them and doesn't re-enable them when libc is loaded.
>How-To-Repeat:
Run GDB on the attached program. Use `next' to step through the program.
Take a look at "maint info break".
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="longjmp.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="longjmp.c"
I2luY2x1ZGUgPHNldGptcC5oPgojaW5jbHVkZSA8c3RkaW8uaD4KCmludAptYWluICh2b2lkKQp7
CiAgam1wX2J1ZiBlbnY7CgogIGlmIChzZXRqbXAgKGVudikpCiAgICB7CiAgICAgIHByaW50ZiAo
ImFmdGVyIHNldGptcFxuIik7CiAgICAgIHJldHVybiAwOwogICAgfQoKICBwcmludGYgKCJiZWZv
cmUgbG9uZ2ptcFxuIik7CiAgbG9uZ2ptcCAoZW52LCAxKTsKICBwcmludGYgKCJhZnRlciBsb25n
am1wXG4iKTsKCiAgcmV0dXJuIDE7Cn0K