[Touch-packages] [Bug 1901966] Re: Unable to stop at breakpoint in 32-bit executable
I've been able to reproduce the problem on 32-bit Ubuntu 20.04 for RPi4. The problem reproduces when the following is linked: ld-linux-armhf.so.3 -> ld-2.31.so* fostja@cptr280-arm:~/code/asm$ gdb -q hello GEF for linux ready, type `gef' to start, `gef config' to configure 75 commands loaded for GDB 9.2 using Python engine 3.8 [*] 5 commands could not be loaded, run `gef missing` to know why. Reading symbols from hello... gef➤ set debug infrun 1 gef➤ b _start Breakpoint 1 at 0x1016c: file hello.s, line 5. gef➤ start infrun: infrun_async(1) infrun: proceed (addr=0xb6fd5a80, signal=GDB_SIGNAL_0) infrun: proceed: resuming process 10100 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10100] at 0xb6fd5a80 infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: handle_inferior_event status->kind = ignore infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: handle_inferior_event status->kind = ignore infrun: prepare_to_wait When I revert to the following then things work properly: ld-linux-armhf.so.3 -> ld-2.28.so* So I have a work-around. It appears that the problem was introduced between 2.28 and 2.31. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1901966 Title: Unable to stop at breakpoint in 32-bit executable Status in gdb package in Ubuntu: New Bug description: I believe I'm having the problem described in #1846557 and #1848200. Those bugs were reported fixed in 8.1.1 but I'm observing them in 9.2 so I suspect a regression (in fact, if I read the notes correctly, the earlier reports were from another regression!). I create a new EC2 server on AWS with Ubuntu Server 20.04 LTS (64-bit Arm) then perform the following installs (not sure what is needed or if something is missing): ``` sudo dpkg --add-architecture armhf sudo apt update sudo apt upgrade -y sudo apt install -y build-essential vim binutils-arm-linux-gnueabi \ gdb libc6:armhf libstdc++6:armhf ``` Then I create hello.s: ``` .text .global _start _start: MOV R7, #4 MOV R0, #1 LDR R1, =hello LDR R2, =hello_size SWI 0 MOV R7, #1 SWI 0 .data hello: .asciz "Hello world!\n" .equhello_size, (.-hello) ``` Then I assemble, link, and run, all with success. Finally, I try to debug: ``` $ arm-linux-gnueabi-as -ggdb -mcpu=cortex-a57 -o out.o hello.s $ arm-linux-gnueabi-ld out.o -dynamic-linker=/usr/lib/ld-linux-armhf.so.3 -o out $ rm out.o $ ./out Hello world! $ gdb out GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 ... Reading symbols from out... (gdb) b _start Breakpoint 1 at 0x10074: file hello.s, line 4. (gdb) run Starting program: /home/ubuntu/280/out ``` At this point everything hangs until I press ^C: ``` ^C Program received signal SIGINT, Interrupt. 0xba072284 in ?? () (gdb) bt #0 0xba072284 in ?? () #1 0x7232 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) l 1 .text 2 .global _start 3 _start: 4 MOV R7, #4 5 MOV R0, #1 6 LDR R1, =hello 7 LDR R2, =hello_size 8 SWI 0 9 MOV R7, #1 10SWI 0 (gdb) q A debugging session is active. Inferior 1 [process 29234] will be killed. Quit anyway? (y or n) y $ ``` It appears that gdb generally works and recognizes the executable, but breakpoints don't work. I'm new at Arm and don't have a lot of experience with assembly (at least not since the early 1970s), so it could easily be my problem but it seems suspiciously like an earlier problem and I think what I've done should work. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1901966/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1901966] Re: Unable to stop at breakpoint in 32-bit executable
** Description changed: I believe I'm having the problem described in #1846557 and #1848200. Those bugs were reported fixed in 8.1.1 but I'm observing them in 9.2 so I suspect a regression (in fact, if I read the notes correctly, the earlier reports were from another regression!). I create a new EC2 server on AWS with Ubuntu Server 20.04 LTS (64-bit Arm) then perform the following installs (not sure what is needed or if something is missing): ``` sudo dpkg --add-architecture armhf sudo apt update sudo apt upgrade -y sudo apt install -y build-essential vim binutils-arm-linux-gnueabi \ - gdb libc6:armhf libstdc++6:armhf + gdb libc6:armhf libstdc++6:armhf ``` Then I create hello.s: ``` - .text - .global _start + .text + .global _start _start: - MOV R7, #4 - MOV R0, #1 - LDR R1, =hello - LDR R2, =hello_size - SWI 0 - MOV R7, #1 - SWI 0 + MOV R7, #4 + MOV R0, #1 + LDR R1, =hello + LDR R2, =hello_size + SWI 0 + MOV R7, #1 + SWI 0 - .data + .data hello: .asciz "Hello world!\n" - .equhello_size, (.-hello) + .equhello_size, (.-hello) ``` Then I assemble, link, and run, all with success. Finally, I try to debug: ``` - $ arm-linux-gnueabi-as -ggdb -mcpu=cortex-a57 -o out.o $@ + $ arm-linux-gnueabi-as -ggdb -mcpu=cortex-a57 -o out.o hello.s $ arm-linux-gnueabi-ld out.o -dynamic-linker=/usr/lib/ld-linux-armhf.so.3 -o out $ rm out.o $ ./out Hello world! $ gdb out GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 ... Reading symbols from out... (gdb) b _start Breakpoint 1 at 0x10074: file hello.s, line 4. (gdb) run - Starting program: /home/ubuntu/280/out + Starting program: /home/ubuntu/280/out ``` At this point everything hangs until I press ^C: ``` ^C Program received signal SIGINT, Interrupt. 0xba072284 in ?? () (gdb) bt #0 0xba072284 in ?? () #1 0x7232 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) l 1 .text 2 .global _start 3 _start: 4 MOV R7, #4 5 MOV R0, #1 6 LDR R1, =hello 7 LDR R2, =hello_size 8 SWI 0 9 MOV R7, #1 10SWI 0 (gdb) q A debugging session is active. - Inferior 1 [process 29234] will be killed. + Inferior 1 [process 29234] will be killed. Quit anyway? (y or n) y $ ``` It appears that gdb generally works and recognizes the executable, but breakpoints don't work. I'm new at Arm and don't have a lot of experience with assembly (at least not since the early 1970s), so it could easily be my problem but it seems suspiciously like an earlier problem and I think what I've done should work. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1901966 Title: Unable to stop at breakpoint in 32-bit executable Status in gdb package in Ubuntu: New Bug description: I believe I'm having the problem described in #1846557 and #1848200. Those bugs were reported fixed in 8.1.1 but I'm observing them in 9.2 so I suspect a regression (in fact, if I read the notes correctly, the earlier reports were from another regression!). I create a new EC2 server on AWS with Ubuntu Server 20.04 LTS (64-bit Arm) then perform the following installs (not sure what is needed or if something is missing): ``` sudo dpkg --add-architecture armhf sudo apt update sudo apt upgrade -y sudo apt install -y build-essential vim binutils-arm-linux-gnueabi \ gdb libc6:armhf libstdc++6:armhf ``` Then I create hello.s: ``` .text .global _start _start: MOV R7, #4 MOV R0, #1 LDR R1, =hello LDR R2, =hello_size SWI 0 MOV R7, #1 SWI 0 .data hello: .asciz "Hello world!\n" .equhello_size, (.-hello) ``` Then I assemble, link, and run, all with success. Finally, I try to debug: ``` $ arm-linux-gnueabi-as -ggdb -mcpu=cortex-a57 -o out.o hello.s $ arm-linux-gnueabi-ld out.o -dynamic-linker=/usr/lib/ld-linux-armhf.so.3 -o out $ rm out.o $ ./out Hello world! $ gdb out GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 ... Reading symbols from out... (gdb) b _start Breakpoint 1 at 0x10074: file hello.s, line 4. (gdb) run Starting program: /home/ubuntu/280/out ``` At this point everything hangs until I press ^C: ``` ^C Program received signal SIGINT, Interrupt. 0xba072284 in ?? () (gdb) bt #0
[Touch-packages] [Bug 1901966] [NEW] Unable to stop at breakpoint in 32-bit executable
Public bug reported: I believe I'm having the problem described in #1846557 and #1848200. Those bugs were reported fixed in 8.1.1 but I'm observing them in 9.2 so I suspect a regression (in fact, if I read the notes correctly, the earlier reports were from another regression!). I create a new EC2 server on AWS with Ubuntu Server 20.04 LTS (64-bit Arm) then perform the following installs (not sure what is needed or if something is missing): ``` sudo dpkg --add-architecture armhf sudo apt update sudo apt upgrade -y sudo apt install -y build-essential vim binutils-arm-linux-gnueabi \ gdb libc6:armhf libstdc++6:armhf ``` Then I create hello.s: ``` .text .global _start _start: MOV R7, #4 MOV R0, #1 LDR R1, =hello LDR R2, =hello_size SWI 0 MOV R7, #1 SWI 0 .data hello: .asciz "Hello world!\n" .equhello_size, (.-hello) ``` Then I assemble, link, and run, all with success. Finally, I try to debug: ``` $ arm-linux-gnueabi-as -ggdb -mcpu=cortex-a57 -o out.o $@ $ arm-linux-gnueabi-ld out.o -dynamic-linker=/usr/lib/ld-linux-armhf.so.3 -o out $ rm out.o $ ./out Hello world! $ gdb out GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 ... Reading symbols from out... (gdb) b _start Breakpoint 1 at 0x10074: file hello.s, line 4. (gdb) run Starting program: /home/ubuntu/280/out ``` At this point everything hangs until I press ^C: ``` ^C Program received signal SIGINT, Interrupt. 0xba072284 in ?? () (gdb) bt #0 0xba072284 in ?? () #1 0x7232 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) l 1 .text 2 .global _start 3 _start: 4 MOV R7, #4 5 MOV R0, #1 6 LDR R1, =hello 7 LDR R2, =hello_size 8 SWI 0 9 MOV R7, #1 10 SWI 0 (gdb) q A debugging session is active. Inferior 1 [process 29234] will be killed. Quit anyway? (y or n) y $ ``` It appears that gdb generally works and recognizes the executable, but breakpoints don't work. I'm new at Arm and don't have a lot of experience with assembly (at least not since the early 1970s), so it could easily be my problem but it seems suspiciously like an earlier problem and I think what I've done should work. ** Affects: gdb (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1901966 Title: Unable to stop at breakpoint in 32-bit executable Status in gdb package in Ubuntu: New Bug description: I believe I'm having the problem described in #1846557 and #1848200. Those bugs were reported fixed in 8.1.1 but I'm observing them in 9.2 so I suspect a regression (in fact, if I read the notes correctly, the earlier reports were from another regression!). I create a new EC2 server on AWS with Ubuntu Server 20.04 LTS (64-bit Arm) then perform the following installs (not sure what is needed or if something is missing): ``` sudo dpkg --add-architecture armhf sudo apt update sudo apt upgrade -y sudo apt install -y build-essential vim binutils-arm-linux-gnueabi \ gdb libc6:armhf libstdc++6:armhf ``` Then I create hello.s: ``` .text .global _start _start: MOV R7, #4 MOV R0, #1 LDR R1, =hello LDR R2, =hello_size SWI 0 MOV R7, #1 SWI 0 .data hello: .asciz "Hello world!\n" .equhello_size, (.-hello) ``` Then I assemble, link, and run, all with success. Finally, I try to debug: ``` $ arm-linux-gnueabi-as -ggdb -mcpu=cortex-a57 -o out.o $@ $ arm-linux-gnueabi-ld out.o -dynamic-linker=/usr/lib/ld-linux-armhf.so.3 -o out $ rm out.o $ ./out Hello world! $ gdb out GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 ... Reading symbols from out... (gdb) b _start Breakpoint 1 at 0x10074: file hello.s, line 4. (gdb) run Starting program: /home/ubuntu/280/out ``` At this point everything hangs until I press ^C: ``` ^C Program received signal SIGINT, Interrupt. 0xba072284 in ?? () (gdb) bt #0 0xba072284 in ?? () #1 0x7232 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) l 1 .text 2 .global _start 3 _start: 4 MOV R7, #4 5 MOV R0, #1 6 LDR R1, =hello 7 LDR R2, =hello_size 8 SWI 0 9 MOV R7, #1 10SWI 0 (gdb) q A debugging session is active. Inferior 1 [process 29234] will be killed. Quit anyway? (y or n) y $
[Touch-packages] [Bug 1848200] Re: gdb not stopping on breakpoint in a 32-bit program
*** This bug is a duplicate of bug 1846557 ***
https://bugs.launchpad.net/bugs/1846557
Will this have been fixed in "GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2"?
I'm having similar problems and came across this report claiming that it
is fixed in "8.1-0ubuntu3.2". I don't understand how the numbers work
but assume that 9.2 has fixes that were in 8.1. If not, then that would
explain my problem.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1848200
Title:
gdb not stopping on breakpoint in a 32-bit program
Status in gdb package in Ubuntu:
Fix Released
Status in gdb source package in Bionic:
Fix Released
Bug description:
[Impact]
After upgrading gdb from 8.1-0ubuntu3 to 8.1-0ubuntu3.1, gdb does not stop
on breakpoint when running a 32-bit application (on 64-bit Ubuntu).
[Test Case]
This can be reproduced with a simple “hello world” program:
$ cat hello.c
#include
int main()
{
// printf() displays the string inside quotation
printf("Hello, World!");
return 0;
}
$ gcc -ggdb -m32 hello.c
$ gdb a.out
(gdb) b hello.c:5
Breakpoint 1 at 0x536: file hello.c, line 5.
(gdb) run
Starting program: /home/user/sandbox/a.out
warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.
--- (and not stopping nor outputting the text…) ---
[Regression Risk]
Test case ran on arm64 and regression tested using the above test case on
amd64, i386 and s390x.
This regression was fixed on the upstream gdb-8.1 branch within a few
weeks of the breakage back in May 2018. Since then there have been no
other fixes in this area on that branch, implying this fixed the issue
and there were no further regressions discovered.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
