[#6469] gdbserver does not handle software breakpoints in 32bit insns correctly

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

[#6469] gdbserver does not handle software breakpoints in 32bit insns correctly

Submitted By: Mike Frysinger

Open Date

2011-02-07 15:01:06    

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: gdbserver does not handle software breakpoints in 32bit insns correctly

Details:

 

gdbserver atm always uses 16bit breakpoints.  a known issue with the hardware is that if you replace only half of a 32bit insn with a 16bit bp, you sometimes get random errors.  gdb itself takes care of detecting whether the insn is 32bit and inserting either a 32bit bp (excpt;nop) or a 16bit bp (excpt).

 

the current gdbserver framework does not easily allow for different sized breakpoints.  so we probably will have to always use 32bit bps for now and figure out with mainline how to support our needs cleanly (since 32bit bps wont always work on 16bit insns at 4KiB boundaries).

 

Follow-ups

 

--- Steve Kilbane                                            2011-02-08 02:55:57

Really? Is there an anomaly number for this? I was under the impression that the

VDSP++ emulator always used 16-bit breakpoints.

 

I can't see a 32-bit overwrite working when you're targeting a 16-bit

instruction, and the following instruction is a jump target.

 

--- Mike Frysinger                                           2011-02-08 10:19:00

true, that would be a downside of using 32bit bps all the time.  this is why gdb

proper will probe the insn before writing out the bp (bfin_breakpoint_from_pc).

i dont think an anomaly # was created for this ... i'll have to ask around.

 

--- Mike Frysinger                                           2011-02-08 14:38:46

previous history can be found in tracker items [#1067] and [#1415]

 

--- Mike Frysinger                                           2011-07-07 15:03:56

here's another in-depth thread documenting the issue as found in kgdb:

http://thread.gmane.org/gmane.linux.hardware.blackfin.kernel.devel/1229

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes