Hide Forgot
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.
The problem persists with gdb-6.3.0.0-1.134.fc5rh.
Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 7 or Fedora 8?
The problem persists on Fedora 8 with gdb-6.6-43.fc8 and kernel-2.6.23.15-137.fc8 .
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
The problem persists on Fedora 10 with gdb-6.8-29.fc10.i386 and kernel-PAE-2.6.27.5-117.fc10.i686.
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?
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.
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.
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
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".)
Posted upstream: http://sourceware.org/ml/gdb-patches/2010-04/msg00059.html