[Touch-packages] [Bug 1901966] Re: Unable to stop at breakpoint in 32-bit executable

2021-10-04 Thread Hyun
I have same issue as James described. A static link of execution file, 
"-static" option in gcc, works in gdb while shared is not.
Any updates on this issue?

bulssi@bulssi:~/work$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04 LTS"
bulssi@bulssi:~/work$ lscpu
Architecture:aarch64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0,1
Off-line CPU(s) list:2,3
Thread(s) per core:  1
Core(s) per socket:  2
Socket(s):   1
Vendor ID:   ARM
Model:   0
Model name:  Cortex-A55
Stepping:r2p0
BogoMIPS:100.00
L2 cache:256 KiB
L3 cache:512 KiB
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf:  Not affected
Vulnerability Mds:   Not affected
Vulnerability Meltdown:  Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:Mitigation; __user pointer sanitization
Vulnerability Spectre v2:Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort:   Not affected
Flags:   fp asimd evtstrm aes pmull sha1 sha2 crc32 
atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
bulssi@bulssi:~/work$ uname -a
Linux bulssi 5.4.96+ #4 SMP PREEMPT Tue Sep 28 02:25:02 UTC 2021 aarch64 
aarch64 aarch64 GNU/Linux
bulssi@bulssi:~/work$ cat test.c

#include 

int main (int argc, char **argv)
{
printf ("hello\n");
return 0;
}
bulssi@bulssi:~/work$ arm-linux-gnueabihf-gcc -o a32.out test.c
bulssi@bulssi:~/work$ ./a32.out
hello
bulssi@bulssi:~/work$ gdb ./a32.out
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.

...

Reading symbols from ./a32.out...
(No debugging symbols found in ./a32.out)
(gdb) set architecture arm
The target architecture is assumed to be arm
(gdb) r
Starting program: /home/bulssi/work/a32.out
^C
Program received signal SIGINT, Interrupt.
0xf7fd12c4 in ?? () from /lib/ld-linux-armhf.so.3
(gdb) bt
#0  0xf7fd12c4 in ?? () from /lib/ld-linux-armhf.so.3
#1  0xf7fc81e4 in ?? () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 
(gdb) set debug infrun 1
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/bulssi/work/a32.out
infrun: infrun_async(1)
infrun: proceed (addr=0xf7fc5a80, signal=GDB_SIGNAL_0)
infrun: proceed: resuming process 19335
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread 
[process 19335] at 0xf7fc5a80
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


^Cinfrun: target_wait (-1.0.0, status) =
infrun:   19335.19335.0 [process 19335],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_INT
infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_INT
infrun: stop_pc = 0xf7fd12fe
infrun: random signal (GDB_SIGNAL_INT)
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun:   process 19335 not executing
infrun: stop_all_threads, pass=1, iterations=1
infrun:   process 19335 not executing
infrun: stop_all_threads done

Program received signal SIGINT, Interrupt.
0xf7fd12fe in ?? () from /lib/ld-linux-armhf.so.3
infrun: infrun_async(0)
(gdb) bt
#0  0xf7fd12fe in ?? () from /lib/ld-linux-armhf.so.3
#1  0xf7fc81e4 in ?? () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) quit
bulssi@bulssi:~/work$ arm-linux-gnueabihf-gcc -static -o a32.out test.c
bulssi@bulssi:~/work$ file a32.out
a32.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), 
statically linked, BuildID[sha1]=e1f35070879490a0c809ac5b4b32159457ae0150, for 
GNU/Linux 3.2.0, not stripped
bulssi@bulssi:~/work$ gdb a32.out
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.

...

Reading symbols from a32.out...
(No debugging symbols found in a32.out)
(gdb) r
Starting program: /home/bulssi/work/a32.out
hello
[Inferior 1 (process 19358) exited normally]
(gdb) quit
bulssi@bulssi:~/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:
  Confirmed

Bug description:
  I believe I'm having the problem described in #1846557 and #1848200.
  Those bugs were reported fixed in 

[Touch-packages] [Bug 1901966] Re: Unable to stop at breakpoint in 32-bit executable

2021-10-04 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: gdb (Ubuntu)
   Status: New => Confirmed

-- 
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:
  Confirmed

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

2020-11-17 Thread James Foster
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

2020-11-13 Thread Luis
This doesn't seem to be related to the previous bugs.

I tried to reproduce this on 18.04.4 (I don't have 20.04) and a fresh
build of GDB master, and I couldn't.

(gdb) disass _start
Dump of assembler code for function _start:
   0x00010074 <+0>: mov r7, #4
   0x00010078 <+4>: mov r0, #1
   0x0001007c <+8>: ldr r1, [pc, #12]   ; 0x10090 <_start+28>
   0x00010080 <+12>:ldr r2, [pc, #12]   ; 0x10094 <_start+32>
   0x00010084 <+16>:svc 0x
   0x00010088 <+20>:mov r7, #1
   0x0001008c <+24>:svc 0x
   0x00010090 <+28>:muleq   r2, r8, r0
   0x00010094 <+32>:andeq   r0, r0, lr
End of assembler dump.
(gdb) b _start
Breakpoint 1 at 0x10074: file /tmp/hello.S, line 4.
(gdb) r
Starting program: /tmp/hello

Breakpoint 1, _start () at /tmp/hello.S:4
4   MOV R7, #4


With Ubuntu 18.04.4's GDB it also works.

Can you please turn on debugging and paste the log?

Use "set debug infrun 1" before the run command.

-- 
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

2020-10-28 Thread James Foster
** 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