From: "Sivanupandi, Pitchumani" <Pitchumani.Sivanupandi@atmel.com>
To: Pedro Alves <palves@redhat.com>,
"troth@openavr.org" <troth@openavr.org>,
"brobecker@adacore.com" <brobecker@adacore.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [patch] Enable dwarf unwind for AVR target
Date: Tue, 05 Jan 2016 06:45:00 -0000 [thread overview]
Message-ID: <CAC140656783604CABA6AE60C2A6D5A4CA3B44A7@penmbx02.corp.atmel.com> (raw)
In-Reply-To: <568A7A4F.2060504@redhat.com>
> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: 04 January 2016 19:28
> To: Sivanupandi, Pitchumani <Pitchumani.Sivanupandi@atmel.com>;
> troth@openavr.org; brobecker@adacore.com; gdb-patches@sourceware.org
> Subject: Re: [patch] Enable dwarf unwind for AVR target
>
> On 01/04/2016 08:01 AM, Sivanupandi, Pitchumani wrote:
> > - AVR_NUM_PSEUDO_REGS = 1,
> > + AVR_DWARF2_PC_REGNUM = 36 /*LR*/,
>
> It's hard to comment without some explanation for the design choices in the
> patch, and/or some understanding of what this register is.
> Seems odd that you create the register and then avr_pseudo_register_read
> already returns <unavailable>? Why did you need to add it? Is this a real
> machine register? What's LR?
>
> > + AVR_NUM_PSEUDO_REGS = 2,
> >
> > AVR_PC_REG_INDEX = 35, /* index into array of registers */
> >
> > @@ -211,7 +213,7 @@ avr_register_name (struct gdbarch *gdbarch, int
> regnum)
> > "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
> > "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31",
> > "SREG", "SP", "PC2",
> > - "pc"
> > + "pc", "LR"
> > };
AVR has only 32 registers. GDB maps status register, SP and PC to numbers 32,
33 and 34 respectively.
Dwarf debug info generated by avr-gcc denotes the return address by register
36 which is not an actual register.
e.g. .debug_frame
(--snip--)
00000000 00000010 ffffffff CIE
Version: 1
Augmentation: ""
Code alignment factor: 2
Data alignment factor: -1
Return address column: 36
DW_CFA_def_cfa: r32 ofs 3
DW_CFA_offset: r36 at cfa-2
(--snip--)
The fix is to add a pseudo register (36 - AVR_DWARF2_PC_REGNUM) to gdb to map
return address register in .debug_frame. Register name is "LR" (link register).
When dwarf frame unwind asks for PC, target function should find return address
value (AVR_DWARF2_PC_REGNUM).
Dwarf frame reader records all registers from the .debug_frame section.
When gdb asks for PC value to unwind, avr_dwarf2_prev_register finds the frame
address recorded for AVR_DWARF2_PC_REGNUM and read value from that memory.
(avr_dwarf2_prev_register implementation is similar to existing
avr_frame_prev_register function)
I assumed pseudo register read/write for this register not mandatory for dwarf
frame unwind. So, left it with dummy implementation as of now.
NOTE:
* Added extern function dwarf2_frame_addr to dwarf2-frame.c to find the frame
address for argument register from dwarf frame cache.
* dwarf2 address size set to 4.
Regards,
Pitchumani
prev parent reply other threads:[~2016-01-05 6:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-04 8:01 Sivanupandi, Pitchumani
2016-01-04 13:57 ` Pedro Alves
2016-01-05 6:45 ` Sivanupandi, Pitchumani [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAC140656783604CABA6AE60C2A6D5A4CA3B44A7@penmbx02.corp.atmel.com \
--to=pitchumani.sivanupandi@atmel.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=troth@openavr.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox