[Bug backtrace/16775] AVR: Backtraces fail when an interrupt handler's prologue saves RAMPZ

[Bug backtrace/16775] AVR: Backtraces fail when an interrupt handler's prologue saves RAMPZ

[justin at jgottula dot com]

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

Justin Gottula <justin at jgottula dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |justin at jgottula dot com

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

[Bug backtrace/16775] New: AVR: Backtraces fail when an interrupt handler's prologue saves RAMPZ

[justin at jgottula dot com]

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

            Bug ID: 16775
           Summary: AVR: Backtraces fail when an interrupt handler's
                    prologue saves RAMPZ
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: backtrace
          Assignee: unassigned at sourceware dot org
          Reporter: justin at jgottula dot com

The function avr_scan_prologue in gdb/avr-tdep.c makes some tight assumptions
about interrupt handler function prologues. In particular, the documentation
says that only the following instructions are expected at the beginning of an
interrupt handler:

   A signal handler prologue looks like this:
        push    __zero_reg__
        push    __tmp_reg__
        in      __tmp_reg__, __SREG__
        push    __tmp_reg__
        clr     __zero_reg__

   A interrupt handler prologue looks like this:
        sei
        push    __zero_reg__
        push    __tmp_reg__
        in      __tmp_reg__, __SREG__
        push    __tmp_reg__
        clr     __zero_reg__

After this, the scanning code expects to find registers being saved on the
stack.

However, on some devices, avr-gcc generates an additional instruction between
these two parts:

000016e2 <__vector_120>:
    16e2:    1f 92           push    r1
    16e4:    0f 92           push    r0
    16e6:    0f b6           in    r0, 0x3f    ; 63
    16e8:    0f 92           push    r0
    16ea:    11 24           eor    r1, r1
    16ec:    0b b6           in    r0, 0x3b    ; 59
    16ee:    0f 92           push    r0
    16f0:    2f 93           push    r18
    16f2:    3f 93           push    r19
    16f4:    4f 93           push    r20
    16f6:    5f 93           push    r21
    16f8:    6f 93           push    r22
    16fa:    7f 93           push    r23
    16fc:    8f 93           push    r24
    16fe:    9f 93           push    r25
    1700:    af 93           push    r26
    1702:    bf 93           push    r27
    1704:    ef 93           push    r30
    1706:    ff 93           push    r31
    1708:    cf 93           push    r28
    170a:    df 93           push    r29
    170c:    1f 92           push    r1
    170e:    cd b7           in    r28, 0x3d    ; 61
    1710:    de b7           in    r29, 0x3e    ; 62

The IO location 0x3b is RAMPZ, which is used to access high memory on AVRs with
large amounts of flash. It's saved in interrupt handlers so that the ISR itself
can access high memory without screwing up high memory accesses in
non-interrupt code.

Obviously this will only ever occur on AVRs that have large amounts of memory,
so not everyone will run into this problem.

To fix the problem, the part of avr_scan_prologue that scans the beginning of
interrupt/signal handlers needs to allow this instruction to be present instead
of immediately expecting a series of 'push's.

(A further note: it might be a good idea to allow for multiple instructions of
this kind at that location, and possibly for IO locations other than RAMPZ, as
there may be cases where avr-gcc also decides to save RAMPX, RAMPY, and/or
RAMPD. I don't have a code example for this, but I am pretty sure it can happen
depending on how the compiler allocates the registers.)

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