This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/16772] New: AVR: Backtraces fail for function prologues with XMEGA-style SP modification


https://sourceware.org/bugzilla/show_bug.cgi?id=16772

            Bug ID: 16772
           Summary: AVR: Backtraces fail for function prologues with
                    XMEGA-style SP modification
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: justin at jgottula dot com

Backtraces of XMEGA programs often don't work because the avr_scan_prologue
function in gdb/avr-tdep.c hasn't kept up with the times WRT modification of
the stack pointer.

In AVRs prior to XMEGA, modifying the stack pointer directly required disabling
interrupts temporarily to prevent corruption. However, XMEGA AVRs have no such
requirement. The XMEGA manual states:

  To prevent corruption when updating the stack pointer from software, a write
  to SPL will automatically disable interrupts for up to four instructions or
  until the next I/O memory write.

And, accordingly, when the function prologues for XMEGA programs modify the
stack pointer, they do so without modifying the global interrupt flag:

00001980 <assert_fail.1469>:
    1980:    cf 93           push    r28
    1982:    df 93           push    r29
    1984:    cd b7           in    r28, 0x3d    ; 61
    1986:    de b7           in    r29, 0x3e    ; 62
    1988:    c0 5c           subi    r28, 0xC0    ; 192
    198a:    d1 09           sbc    r29, r1
    198c:    cd bf           out    0x3d, r28    ; 61
    198e:    de bf           out    0x3e, r29    ; 62

However, the documentation for avr_scan_prologue says:

   A typical AVR function prologue with a frame pointer might look like this:
        push    rXX        ; saved regs
        ...
        push    r28
        push    r29
        in      r28,__SP_L__
        in      r29,__SP_H__
        sbiw    r28,<LOCALS_SIZE>
        in      __tmp_reg__,__SREG__
        cli
        out     __SP_H__,r29
        out     __SREG__,__tmp_reg__
        out     __SP_L__,r28

and:

   A interrupt handler prologue looks like this:
        sei
        push    __zero_reg__
        push    __tmp_reg__
        in      __tmp_reg__, __SREG__
        push    __tmp_reg__
        clr     __zero_reg__
        push    rXX             ; save registers r18:r27, r30:r31
        ...
        push    r28             ; save frame pointer
        push    r29
        in      r28, __SP_L__
        in      r29, __SP_H__
        sbiw    r28, <LOCALS_SIZE>
        cli
        out     __SP_H__, r29
        sei     
        out     __SP_L__, r28

And, indeed, avr_scan_prologue will fail to scan a function prologue that
modifies the stack pointer without the interrupt toggling steps (for example,
the function prologue I provided above).

The code (scan_stage 2 of avr_scan_prologue) needs to be updated to accommodate
both ways of modifying the stack pointer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]