Bug 162775 - gdb ignores SIGTRAP at entry address
gdb ignores SIGTRAP at entry address
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
12
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Kratochvil
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-08 12:00 EDT by John Reiser
Modified: 2010-04-05 16:23 EDT (History)
0 users

See Also:
Fixed In Version: gdb-7.1-8.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-05 16:23:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 9436 None None None Never

  None (edit)
Description John Reiser 2005-07-08 12:00:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
gdb does not report the SIGTRAP which occurs due to the 'int3' instruction at the entry address.
----- int3.S
_start: .globl _start
        int3

        movl $42,%ebx
        movl $1,%eax
        int $0x80
-----
gcc -nostartfiles -nostdlib -o int3 int3.S


Version-Release number of selected component (if applicable):
gdb-6.3.0.0-1.21

How reproducible:
Always

Steps to Reproduce:
1. Compile the program in the Description.
2. Run directly under shell.
3. Run under gdb.
  

Actual Results:  $ ./int3
Trace/breakpoint trap   ## good; expected
$ gdb ./int3
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
   . . .
(gdb) run
Starting program: /home/jreiser/int3
Reading symbols from shared object read from target memory...(no debugging symbols found)...done.
Loaded system supplied DSO at 0x7b8000

Program exited with code 052.   ## bad: SIGTRAP not reported.
(gdb) q


Expected Results:  gdb should have reported the SIGTRAP which occurs upon execution of the first instruction.  If the program is modified by inserting a 'nop' as the first instruction (before the 'int3'), then gdb reports correctly:
-----
(gdb) run
Starting program: /home/jreiser/int3
Reading symbols from shared object read from target memory...(no debugging symbols found)...done.
Loaded system supplied DSO at 0x7e1000

Program received signal SIGTRAP, Trace/breakpoint trap.
0x08048076 in _start ()
-----


Additional info:

This is a refinement of bug 160915.
Comment 1 John Reiser 2006-10-17 16:37:18 EDT
The problem persists with gdb-6.3.0.0-1.134.fc5rh.
Comment 2 petrosyan 2008-03-10 11:37:09 EDT
Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 7 or
Fedora 8?
Comment 3 John Reiser 2008-03-10 11:51:52 EDT
The problem persists on Fedora 8 with gdb-6.6-43.fc8
and kernel-2.6.23.15-137.fc8 .
Comment 4 Bug Zapper 2008-11-26 01:51:40 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 John Reiser 2008-11-28 14:49:54 EST
The problem persists on Fedora 10 with gdb-6.8-29.fc10.i386 and kernel-PAE-2.6.27.5-117.fc10.i686.
Comment 6 Jan Kratochvil 2008-12-02 07:56:18 EST
While it does not fix this specific testcase it fixes the problem if you place a breakpoint at _start:
http://sourceware.org/ml/archer/2008-q4/msg00358.html
http://sourceware.org/gdb/wiki/ArcherBranchManagement
archer-jankratochvil-misc
e25caae08e0092125d06450426bd03cb57f6eb0b

Is it a sufficient fix?  I was facing this problem myself but not with the permanent breakpoint as you show in the Comment 0.  Do you have some more real world example for the bugreported problem?
Comment 7 John Reiser 2008-12-02 15:06:59 EST
The example which is more real-world is related to bug 179072, _dl_debug_state() RT_CONSISTENT called too early.  The underlying goal is to track changes to the address space at the highest semantic level possible, while still maintaining control and the ability to intercept and override such changes easily.  glibc errs using its own _dl_debug_state, and does not cooperate with outside changes to r_debug.r_brk.  Trying other methods [and other aspects], kernel+ptrace+gdb have problems with int3 and/or breakpoint at .e_entry.

The original bug 160915 "int3 trap at entry address is not delivered under ptrace" was refined into this bug 162775 because of claims by kernel maintainer that the kernel was doing the right thing.  If the entry sequence is "nop; int3" then gdb reports the SIGTRAP at 2+.e_entry (not 1+.e_entry), so the SIGTRAP happens *after* the int3 has been executed.  If the entry sequence is just "int3" (with no preceding 'nop') then the kernel delivers SIGTRAP with $pc==(1+.e_entry).  Why does gdb ignore it?  int3 happens to be what gdb uses to implement breakpoints, but gdb did not write into the address space, so the SIGTRAP cannot be the result of a gdb breakpoint.  Also, if under ptrace then the kernel delivers a SIGTRAP immediately after execve(), *before* the first instruction.  This SIGTRAP will be at $pc==.e_entry.  So the cases for $pc of SIGTRAP are:
     .e_entry   ptrace after execve(), and before 1st instruction
     .e_entry   user sequential execution [such as fall-through from
                   $pc < .e_entry], at least 1 instruction after execve()
   1+.e_entry   gdb breakpoint at .e_entry
   1+.e_entry   user sequential execution, at least 1 instruction after execve()
                [includes case of user int3 at .e_entry]
    any other   not disputed
It still seems to me that gdb should distinguish these cases, and not fail to report the SIGTRAP when there is a user int3 at .e_entry.
Comment 8 Jan Kratochvil 2008-12-02 15:32:59 EST
The problem of GDB with int3 at the entry point is very high-level, unrelated to kernel/ptrace.  You may check it with:
$ ./gdb -nx -ex 'set debug infrun 1' -ex r /tmp/int3
infrun: proceed (addr=0xffffffffffffffff, signal=0, step=0)
infrun: resume (step=1, signal=0), trap_expected=1
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8048098
infrun: check_shlib
infrun: no stepping, continue
infrun: resume (step=1, signal=0), trap_expected=1
...

In the small sample file GDB fails to find _dl_debug_state() as no libc is linked there and so it falls back to at least place the shared libraries notification breakpoint at _start (I do not know myself if it can be useful anyhow but GDB thinks so).  GDB understandably automatically continues the execution when it hits the shared libraries notification breakpoint.

The patch from Comment 6 handles a case when you place a user breakpoint at the same place as the shared libraries notification breakpoint - like `break _dl_debug_state'.  But it does not handle the case when the inferior is built with a breakpoint instruction at the address _dl_debug_state.

With these issues please also check on you CPU+kernel the so far unresolved
Bug 439668 which may be related to it.

I will yet check+reproduce your points of the comment more, thanks.
Comment 9 Bug Zapper 2009-11-18 03:03:50 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 John Reiser 2009-11-18 13:55:03 EST
The problem persists in F12 with gdb-7.0-3.fc12.i686 under kernel-PAE-2.6.31.5-127.fc12.i686.  (Changing Version of this bug to "12".)
Comment 11 Jan Kratochvil 2010-04-04 17:09:21 EDT
Posted upstream:
http://sourceware.org/ml/gdb-patches/2010-04/msg00059.html

Note You need to log in before you can comment on or make changes to this bug.