REGISTER_BYTE() and pseudos

REGISTER_BYTE() and pseudos

[Richard Earnshaw]

What should REGISTER_BYTE() return for a pseudo that doesn't have space 
allocated in registers[]?

R.

Re: REGISTER_BYTE() and pseudos

[Andrew Cagney]

> What should REGISTER_BYTE() return for a pseudo that doesn't have space 
> allocated in registers[]?

It shouldn't matter.  However, check with Elena for what was done with 
the sh5.

Andrew

Re: REGISTER_BYTE() and pseudos

[Elena Zannoni]

Andrew Cagney writes:
 > > What should REGISTER_BYTE() return for a pseudo that doesn't have space 
 > > allocated in registers[]?
 > 
 > It shouldn't matter.  However, check with Elena for what was done with 
 > the sh5.
 > 
 > Andrew
 > 
 > 

Yeah, I was going to chime in, but I am behind on this thread.
Richard, look at the sh-tdep.c file. I checked in the sh5 work.  It
still needs another round of cleaning but ti should pretty much all be
there.

Elena

Re: REGISTER_BYTE() and pseudos

[Richard Earnshaw]

> Yeah, I was going to chime in, but I am behind on this thread.
> Richard, look at the sh-tdep.c file. I checked in the sh5 work.  It
> still needs another round of cleaning but ti should pretty much all be
> there.

OK, I'll have another look.  

The bit I'm worried about though is if we call something like 
generic_get_saved_register for a pseudo and we hit a call_dummy frame.  
The code in there goes:

      if (PC_IN_CALL_DUMMY (frame->pc, frame->frame, frame->frame))
        {
          if (lval)             /* found it in a CALL_DUMMY frame */
            *lval = not_lval;
          if (raw_buffer)
            memcpy (raw_buffer,
                    generic_find_dummy_frame (frame->pc, frame->frame) +
                    REGISTER_BYTE (regnum),
                    REGISTER_RAW_SIZE (regnum));
          return;

Which will try to look up the pseudo in the buffer even if it isn't there.

Re: REGISTER_BYTE() and pseudos

[Elena Zannoni]

Richard Earnshaw writes:
 > 
 > > Yeah, I was going to chime in, but I am behind on this thread.
 > > Richard, look at the sh-tdep.c file. I checked in the sh5 work.  It
 > > still needs another round of cleaning but ti should pretty much all be
 > > there.
 > 
 > OK, I'll have another look.  
 > 
 > The bit I'm worried about though is if we call something like 
 > generic_get_saved_register for a pseudo and we hit a call_dummy frame.  
 > The code in there goes:
 > 
 >       if (PC_IN_CALL_DUMMY (frame->pc, frame->frame, frame->frame))
 >         {
 >           if (lval)             /* found it in a CALL_DUMMY frame */
 >             *lval = not_lval;
 >           if (raw_buffer)
 >             memcpy (raw_buffer,
 >                     generic_find_dummy_frame (frame->pc, frame->frame) +
 >                     REGISTER_BYTE (regnum),
 >                     REGISTER_RAW_SIZE (regnum));
 >           return;
 > 
 > Which will try to look up the pseudo in the buffer even if it isn't there.

Hmmm, yes you are probably right. That case is likely broken then.

Elena

Re: REGISTER_BYTE() and pseudos

[Richard Earnshaw]

OK, I see what you are doing.  Basically, if a pseudo maps onto a real 
register somewhere in the regcache, you return the address of that.

However, what should be done if the pseudo doesn't exist as a single 
entry, or if it is a manipulation of a real register?  For example, on the 
ARM, the CPSR may be just a few bits retrieved from the PC.

Also, what would you do if you needed to address two non-adjacent 
registers?

R.

Re: REGISTER_BYTE() and pseudos

[Elena Zannoni]

Richard Earnshaw writes:
 > OK, I see what you are doing.  Basically, if a pseudo maps onto a real 
 > register somewhere in the regcache, you return the address of that.
 > 
 > However, what should be done if the pseudo doesn't exist as a single 
 > entry, or if it is a manipulation of a real register?  For example, on the 
 > ARM, the CPSR may be just a few bits retrieved from the PC.
 > 
 > Also, what would you do if you needed to address two non-adjacent 
 > registers?
 > 
 > R.

Look at sh64_pseudo_register_read() and how FPSCR is treated.  FPSCR
is built as a collection of non-adjacent bits in various architectural
registers.

In theory sh64_pseudo_register_read shouldn't even be there.  All that
code should just be part of sh64_register_read.  Basically
sh64_register_read just does what it wants with the registers, almost
like if there was no difference between pseudos and real registers.

Same with sh64_register_write and sh64_pseudo_register_write.

Elena

Re: REGISTER_BYTE() and pseudos

[Andrew Cagney]

> OK, I see what you are doing.  Basically, if a pseudo maps onto a real 
> register somewhere in the regcache, you return the address of that.
> 
> However, what should be done if the pseudo doesn't exist as a single 
> entry, or if it is a manipulation of a real register?  For example, on the 
> ARM, the CPSR may be just a few bits retrieved from the PC.
> 
> Also, what would you do if you needed to address two non-adjacent 
> registers?

Return ``not_lval''.  I think that case can go in the too hard basket.

First, I don't know if GDB's ``struct value'' system is rich enough to 
describe a value split across [disjoint] registers and memory.  Second, 
even if it was, the current get_saved_register() doesn't make that 
knowledge available.  An interface more like value_of_register() would 
be better.

BTW, this code:

 > OK, I'll have another look.
 >
 > The bit I'm worried about though is if we call something like
 > generic_get_saved_register for a pseudo and we hit a call_dummy frame.
 > The code in there goes:
 >
 >       if (PC_IN_CALL_DUMMY (frame->pc, frame->frame, frame->frame))
 >         {
 >           if (lval)             /* found it in a CALL_DUMMY frame */
 >             *lval = not_lval;
 >           if (raw_buffer)
 >             memcpy (raw_buffer,
 >                     generic_find_dummy_frame (frame->pc, frame->frame) +
 >                     REGISTER_BYTE (regnum),
 >                     REGISTER_RAW_SIZE (regnum));
 >           return;
 >
 > Which will try to look up the pseudo in the buffer even if it isn't 
there.


Reveals a problem with the patch:
http://sources.redhat.com/ml/gdb-patches/2002-05/msg00416.html

For the moment a custom get_saved_register will get around this.


Andrew