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/16774] New: AVR: Backtraces fail when r1 is used to subtract from the frame pointer


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

            Bug ID: 16774
           Summary: AVR: Backtraces fail when r1 is used to subtract from
                    the frame pointer
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: justin at jgottula dot com

The function avr_scan_prologue in gdb/avr-tdep.c provides for two ways that a
function prologue might allocate space for locals. The documentation for the
function says:

   Some devices lack the sbiw instruction, so on those replace this:
        sbiw    r28, XX
   with this:
        subi    r28,lo8(XX)
        sbci    r29,hi8(XX)

and:

     Scan for:
     sbiw r28,XX or subi r28,lo8(XX)
                    sbci r29,hi8(XX)

However, I have come across a third case that avr-gcc will sometimes generate:

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

Here, r1 (the zero register) is used in the second half of the subtraction
instead of doing, say, 'sbci r29,0'.

Unfortunately, when avr_scan_prologue sees the subi instruction in scan_stage
2, it assumes that the next instruction will be sbci and extracts bits to
determine how much was subtracted.

This will obviously not work correctly if the second instruction is not sbci
(in this particular case, I believe it will extract 0xfe as the supposed
immediate value; clearly, wrong). This breaks backtraces.

The code needs an extra case to check for 'sbc r29, r1' and act accordingly.

-- 
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]