* FP aliases
@ 2003-05-28 23:46 Svein E. Seldal
2003-05-29 16:11 ` Andrew Cagney
0 siblings, 1 reply; 5+ messages in thread
From: Svein E. Seldal @ 2003-05-28 23:46 UTC (permalink / raw)
To: gdb
Hi,
From the docs in gdb/std-regs.c:75, value_of_builtin_frame_fp_reg() it
states that it will automagically use any registers named "fp" as fp
(instead of using the deprecated fp functions). So what I read is that I
need to reply "fp" in one of the registers in the
set_gdbarch_register_name() function, right?
For my arch, the tic4x, there is no hardware registers named "fp". Is it
wise to replace my "ar3" with "fp". Users will probably get confused
when they are introduced to the "fp" register, as they do not know the
physical relation. But it states that I can create an alias. How? And
why is that dangerous?
I also observere that for the d10v target, no register is named "fp",
but still they manage to do without the the deprecated fp functions. How
is that?
Regards,
Svein
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: FP aliases
2003-05-28 23:46 FP aliases Svein E. Seldal
@ 2003-05-29 16:11 ` Andrew Cagney
2003-05-29 19:49 ` Svein E. Seldal
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cagney @ 2003-05-29 16:11 UTC (permalink / raw)
To: Svein E. Seldal; +Cc: gdb
> Hi,
>
> From the docs in gdb/std-regs.c:75, value_of_builtin_frame_fp_reg() it states that it will automagically use any registers named "fp" as fp (instead of using the deprecated fp functions). So what I read is that I need to reply "fp" in one of the registers in the set_gdbarch_register_name() function, right?
The user guide documentation for $fp reads:
> @value{GDBN} has four ``standard'' register names that are available (in
> expressions) on most machines---whenever they do not conflict with an
> architecture's canonical mnemonics for registers. The register names
> @code{$pc} and @code{$sp} are used for the program counter register and
> the stack pointer. @code{$fp} is used for a register that contains a
> pointer to the current stack frame, and @code{$ps} is used for a
> register that contains the processor status. For example,
> you could print the program counter in hex with
If your architecture does not have a $fp, do not try to provide it. GDB
will map $fp onto the frame's base address (as defined by the debug info).
All this goes back to a very old ARM bug where $fp gave different values
in different contexts vis:
(gdb) print $fp
(gdb) info registers fp
> For my arch, the tic4x, there is no hardware registers named "fp". Is it wise to replace my "ar3" with "fp". Users will probably get confused when they are introduced to the "fp" register, as they do not know the physical relation. But it states that I can create an alias. How? And why is that dangerous?
Only include $fp in the register names when there is a register, as
defined by the ISA, that has the name "fp".
The d10v doesn't have a register called FP, so doesn't provide "fp".
Instead, $fp is mapped onto the frame's base address.
> I also observere that for the d10v target, no register is named "fp", but still they manage to do without the the deprecated fp functions. How is that?
Yes. An architecture function is deprecated when either: it isn't
needed at all (as with FP_REGNUM, READ_FP); or has been made redundant
by a newer mechanism.
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: FP aliases
2003-05-29 16:11 ` Andrew Cagney
@ 2003-05-29 19:49 ` Svein E. Seldal
2003-05-29 20:01 ` Andrew Cagney
0 siblings, 1 reply; 5+ messages in thread
From: Svein E. Seldal @ 2003-05-29 19:49 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
Andrew Cagney wrote:
> If your architecture does not have a $fp, do not try to provide it. GDB
> will map $fp onto the frame's base address (as defined by the debug info).
<snip>
> Only include $fp in the register names when there is a register, as
> defined by the ISA, that has the name "fp".
>
> The d10v doesn't have a register called FP, so doesn't provide "fp".
> Instead, $fp is mapped onto the frame's base address.
Well, the trick is that tic4x-gcc assigns ar3 as an fp register (at all
times), so you wind up stuck in the middle here. You have an FP-like
register, yet it's not named FP.
But I've rough-ported the d10v unwind mechanisms to the tic4x port, and
it seems like I am able to work it out without the fp register. (Still,
I need to understand those unwind things..)
> Yes. An architecture function is deprecated when either: it isn't
> needed at all (as with FP_REGNUM, READ_FP); or has been made redundant
> by a newer mechanism.
Yes, and its these new mechanisms I'm trying to work out. I'll take a
look at the i386 port, and see if I'm able to resolve its functionality
from that.
Svein
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: FP aliases
2003-05-29 19:49 ` Svein E. Seldal
@ 2003-05-29 20:01 ` Andrew Cagney
2003-05-29 20:41 ` Svein E. Seldal
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Cagney @ 2003-05-29 20:01 UTC (permalink / raw)
To: Svein E. Seldal; +Cc: gdb
> Well, the trick is that tic4x-gcc assigns ar3 as an fp register (at all times),
What of -fomit-frame-pointer? GDB's past mistake was to assume, as your
suggesting, that $fp is always a hard register. Unfortunatly, GCC
eventually got better ideas (and eliminated that assumption) causing GDB
to fall apart.
> you wind up stuck in the middle here. You have an FP-like register,
yet it's not named FP.
> But I've rough-ported the d10v unwind mechanisms to the tic4x port, and it seems like I am able to work it out without the fp register.
Yes, GDB's FP isn't a real register.
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: FP aliases
2003-05-29 20:01 ` Andrew Cagney
@ 2003-05-29 20:41 ` Svein E. Seldal
0 siblings, 0 replies; 5+ messages in thread
From: Svein E. Seldal @ 2003-05-29 20:41 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
Andrew Cagney wrote:
> What of -fomit-frame-pointer? GDB's past mistake was to assume, as your
> suggesting, that $fp is always a hard register. Unfortunatly, GCC
> eventually got better ideas (and eliminated that assumption) causing GDB
> to fall apart.
Now I suddenly realize why gdb isn't sticking around with the FP methods!
Thanks,
Svein
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-05-29 20:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-28 23:46 FP aliases Svein E. Seldal
2003-05-29 16:11 ` Andrew Cagney
2003-05-29 19:49 ` Svein E. Seldal
2003-05-29 20:01 ` Andrew Cagney
2003-05-29 20:41 ` Svein E. Seldal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).