FP aliases

FP aliases

[Svein E. Seldal]

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

Re: FP aliases

[Andrew Cagney]

> 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

Re: FP aliases

[Svein E. Seldal]

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

Re: FP aliases

[Andrew Cagney]

> 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

Re: FP aliases

[Svein E. Seldal]

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