I am trying to debug a simple assembly language program in gdb and setting a breakpoint at the _start label(line 5), but when I run it, the program stops one line after on line 6, not on line 5.

I cannot find the reason for this behaviour on google or from my searches on the Raspbian bug database.

To repeat the steps below, run the program on a Raspberry Pi 3 running Raspbian 8.0 Jessie and gdb version 7.7.1

1 @filename: P2_1.s -- program adds contents of two registers together.
3 .text
4 .global _start
5 _start:  MOV R1, #0x25     @storing 25 hex in R1
6          MOV R2, #0x34     @storing 34 hex in R2
7          ADD R3, R2, R1    @adding R1 and R2
8 HERE:   B   HERE           @infinite loop
9 .end    

Compile and link including debug symbols like this:

$ as -g -o P2_1.o P2_1.s; ld -o P2_1 P2_1.o

Then run gdb like this:

$ gdb P2_1

Then in gdb add a breakpoint at the _start label like this:

(gdb) break _start
Breakpoint 1 at 0x10058: file P2_1.s, line 6.

The breakpoint is added to line 6 not line 5. When you run it, it should stop at line 5, but it doesnt. It stops at line 6.

Is this normal behaviour of gdb or is it a bug?


This is not an actual solution to this question and I really do not think this question belong here. But here is what forum says.

  1. http://sourceware.org/ml/gdb-patches/2012-08/msg00148.html

This is a pretty old post which says the similar issue reported by you.

  1. Also there is a stackquestion as well here


But interesting its something new for me as well. As far as people reported this issue has been there till 7.4 version.

| improve this answer | |
  • My guess is when it sees the breakpoint being fetched it stops and shows the next address. It will never stop on the first address of subroutine unless set a breakpoint on the "call" instruction. There may be several places that call subroutine, but gdb has know way of knowing this. – PaulF8080 Dec 3 '16 at 6:58
  • Thanks for the answer Varad. I went and checked that stackoverflow post about the similar behaviour(bug) in gdb and ran the code example on that page and confirmed that that bug no longer exists in my version of GDB 7.7.1 so unfortunately that bug/behaviour is not the same as the one I posted above. – Jerry Marbas Dec 4 '16 at 4:16
  • @Varad you may be right and my question doesnt belong here so I submitted a bug report about this issue in their gdb's bug tracking database sourceware.org/bugzilla/show_bug.cgi?id=20926 – Jerry Marbas Dec 5 '16 at 5:00
  • @JerryMarbas Cool. However I suggest if you get updates don't forget the update here. – Varad A G Dec 5 '16 at 7:35
  • I wouldn't count on defects being fixed anytime soon. I saw lots of bugs in there that were submitted years ago and aren't even assigned to anyone. The average time it takes to fix opensource bugs is about 5 years. youtu.be/aMkCKeZ8xZw – Jerry Marbas Dec 24 '16 at 10:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.