[#6682] gdb sometimes sets 16bit software bp in the 2nd half of a 32bit insn

Document created by Aaronwu Employee on Oct 17, 2013
Version 1Show Document
  • View in full screen mode

[#6682] gdb sometimes sets 16bit software bp in the 2nd half of a 32bit insn

Submitted By: Mike Frysinger

Open Date

2011-07-07 15:13:08    

Priority:

Medium     Assignee:

Nobody

Board:

N/A     Silicon Revision:

Resolution:

N/A     Fixed In Release:

N/A

Processor:

ALL     

Host Operating System:

toolchain rev.:

    kernel rev.:

State:

Open     Found In Release:

N/A

Is this bug repeatable?:

N/A     

Summary: gdb sometimes sets 16bit software bp in the 2nd half of a 32bit insn

Details:

 

in the attached code (breakpoint.s) you will find:

...

_random:

        R3.H = (A1 += R7.L * R5.H) (M, IS);

...

 

if we build this and run it under Linux, it works fine.  if you run it through gdbserver and set a breakpoint on "random", things will be placed at the wrong location.

 

so compile the code:

$ bfin-linux-uclibc-gcc -Wa,--defsym,BFIN_HOST=1 -g -o breakpoint.s.X breakpoint.s -static

 

copy it to the board:

$ rcp breakpoint.s.X root@bfin:/

 

start up gdbserver:

$ gdbserver :1234 /breakpoint.s.X

 

connect with gdb:

$ bfin-linux-uclibc-gdb ./breakpoint.s.X

(gdb) target remote bfin:1234

Remote debugging using bfin:1234

_start () at libc/sysdeps/linux/bfin/crt1.S:63

63              call    .Lcall;

 

then set a breakpoint on "random":

(gdb) b random

Function Prologue not recognised. pc will point to ENTRY_POINT of the function

Breakpoint 2 at 0x291c488: file breakpoint.s, line 50.

 

the problem is the address it picked is the middle of the 32bit insn:

(gdb) disassemble random

Dump of assembler code for function random:

0x0291c486 <random+0>:  R3.H = (A1 += R7.L * R5.H) (M, IS);

0x0291c48a <random+4>:  R6.H = R6.L - R0.H (S);

...

 

0x0291c486 is the start of random while 0x0291c488 is 16bits into the 32bit.  so before, the memory looks like:

(gdb) x/4b random

0x291c486 <random>:     0x15    0xc1    0xfd    0x58

and after the breakpoint has been placed, it looks like:

0x291c486 <random>:     0x15    0xc1    0xa1    0x00

when it should be:

0x291c486 <random>:     0xa1    0x00    0xfd    0x58

 

you can easily verify this by additionally connecting jtag (gdbproxy), putting an "emuexcpt" insn in the breakpoint.s file before _random, and then connecting a 2nd gdb instance.  with gdbserver, say "continue", and when emuexcpt is hit in the 2nd gdb, you can view what gdb+gdbserver has been replacing.

 

this can be worked around by doing "b *random" ...

 

Follow-ups

No Messages Were Found

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

testutils.inc    application/octet-stream    5245    Mike Frysinger

breakpoint.s    text/x-asm    1274    Mike Frysinger

Attachments

Outcomes