Hi Yao,

I don't know if you remember, but we discussed an ARM patch back
in Dec 2010, which was adding support for skipping stack-check-guard
code as part of the prologue:
https://www.sourceware.org/ml/gdb-patches/2010-12/msg00110.html

I discovered that the heuristic used is mistakenly thinking that
some code that fetches a global is some stack_chk_guard code,
which, in turn, causes the debugger to skip it when inserting
breakpoints.

The full code is attached, but I suspect you will not have the Ada
compiler to build it. But I can send you the binary if you need it.
At this point, I am just trying to collect for more info.

In our case, we're trying to insert a breakpoint on str.adb:4,
where the code looks like this:

  3 procedure STR is
  4    XX : String (1 .. Blocks.Sz) := (others => 'X'); -- STOP
  5    K : Integer;
  6 begin
  7    K := 13;

Line 4 declares a new variable "XX" whihch is an array whose
size is determined by the value of a global variable "Sz"
from package "Blocks", and then assigns it an initial value
(all 'X'-s).

The generated code starts like this:

    (gdb) disass str'address
    Dump of assembler code for function _ada_str:
       --# Line str.adb:3
       0x08000014 <+0>:     push    {r4, r7, lr}
       0x08000016 <+2>:     sub     sp, #28
       0x08000018 <+4>:     add     r7, sp, #0
       0x0800001a <+6>:     mov     r3, sp
       0x0800001c <+8>:     mov     r4, r3
       --# Line str.adb:4
       0x0800001e <+10>:    ldr     r3, [pc, #84]   ; (0x8000074 <_ada_str+96>)
       0x08000020 <+12>:    ldr     r3, [r3, #0]
       0x08000022 <+14>:    str     r3, [r7, #20]
       0x08000024 <+16>:    ldr     r3, [r7, #20]
       [...]

When computing the address related to str.adb:4, GDB correctly
resolves it to 0x0800001e first, but then considers the next
3 instructions as being part of the prologue because it thinks
they are part of stack-protector code. As a result, instead
of inserting the breakpoint at line 4, it skips those instruction
and consequently the rest of the instructions until the next
line start, which his line 7.

Looking at the implementation of the prologue analyzing, it seems
that a normal sequence would be what you put in the comments:

        ldr     Rn, .Label
        ....
        .Lable:
        .word   __stack_chk_guard

But the implementation seems to be going further than that.
If the location of the first ldr points to data that's not
the address of __stack_chk_guard, then it looks at the next
two instructions, to see if they might following another
pattern:

      /* Step 2: ldr Rd, [Rn, #immed], encoding T1.  */
      /* Step 3: str Rd, [Rn, #immed], encoding T1.  */

Looking at the code and the function description, it seems to me
that the normal situation would be what the comment alluded to,
and that if it was the entire story, we wouldn't have needed
the code doing steps 2 & 3. But, looking at the email archives
as well as the bug report initially referenced, I can't find
really any explanation for what prompted you to add that code.
I would need that in order to adjust the heuristics without
breaking your situation.

Do you remember, by any chance?

-- 
Joel