Invalid registers

Invalid registers

[Andrew STUBBS]

Hi,

I have been having a little trouble updating from GDB 5.3 to GDB 6.3.

It used to be the case that GDB would report '*value not available*' (for  
SH - I haven't checked other architectures) if the value of a register is  
not known in the current stack frame. However, it no longer does this.  
Since I assume it has not acquired some way to find out what that value  
was, I also assume this is somehow broken.

(Note that SH already was broken in this respect for fp registers etc.)

The code to print the data, in sh-tdep.c, has not changed greatly. It  
still calls frame_register_read() to discover the status of each register.  
However, deep in regcache.c, the code to handle this sort of thing has  
changed somewhat (indeed a few 'deprecated_...'s have got into the mix).  
The result is that no register is ever marked invalid.

I cannot find out how (or where) it is supposed to know whether a register  
is invalid or not. Nor can I find any relevant discussion on the subject  
by googling (or I don't recognise it when I see it).

Has this problem been fixed since 6.3 or become somehow obsolete? If not,  
any clues how to fix it?

Thanks

Andrew Stubbs

Re: Invalid registers

[Daniel Jacobowitz]

On Mon, Jul 11, 2005 at 04:39:51PM +0100, Andrew STUBBS wrote:
> Hi,
> 
> I have been having a little trouble updating from GDB 5.3 to GDB 6.3.
> 
> It used to be the case that GDB would report '*value not available*' (for  
> SH - I haven't checked other architectures) if the value of a register is  
> not known in the current stack frame. However, it no longer does this.  
> Since I assume it has not acquired some way to find out what that value  
> was, I also assume this is somehow broken.

How's it supposed to know that the value is not available?  If you want
to do this based on the standard call ABI, please take a look at the
current callers of dwarf2_frame_set_init_reg.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Invalid registers

[Marcel Moolenaar]

On Jul 11, 2005, at 8:49 AM, Daniel Jacobowitz wrote:

> On Mon, Jul 11, 2005 at 04:39:51PM +0100, Andrew STUBBS wrote:
>> Hi,
>>
>> I have been having a little trouble updating from GDB 5.3 to GDB 6.3.
>>
>> It used to be the case that GDB would report '*value not available*' 
>> (for
>> SH - I haven't checked other architectures) if the value of a 
>> register is
>> not known in the current stack frame. However, it no longer does this.
>> Since I assume it has not acquired some way to find out what that 
>> value
>> was, I also assume this is somehow broken.
>
> How's it supposed to know that the value is not available?

Given that registers are available when a value has been supplied,
it's logical to assume (a priori) that a register is unavailable
when no value has been supplied. A register's valid "bit" allows
for this since there are 2 states that indicate unavailability:
One that indicates a temporary state (0) and one that indicates a
permanent state (-1). The initial state of a register is the temporarily
unavailable state, which triggers fetching the register from the
target. The target can change the state to permanently unavailable
or supply the value (it can also, theoretically at least, leave the
state unmodified and not provide a value). Hence, the a priori
assumption that registers are unavailable when no value has been
supplied (i.e. when the valid "bit" is not 1) seems to yield good
behaviour when implemented as such. I would say then that gdb knows
when a value is not available.

Unfortunately, there are various bugs in this respect. A typical
bug is to test for (register_valid_p[regnum]) to check if the
register is cached, which ignores the <0 state for unavailable.

-- 
  Marcel Moolenaar         USPA: A-39004          marcel@xcllnt.net

Re: Invalid registers

[Daniel Jacobowitz]

On Mon, Jul 11, 2005 at 11:47:01AM -0700, Marcel Moolenaar wrote:
> Given that registers are available when a value has been supplied,
> it's logical to assume (a priori) that a register is unavailable
> when no value has been supplied.

You are talking about a completely different meaning of unavailable
than Andrew was.  He's talking about unwinding, i.e. registers which
have been modified but not saved by an intervening stack frame.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Invalid registers

[Marcel Moolenaar]

On Jul 11, 2005, at 11:51 AM, Daniel Jacobowitz wrote:

> On Mon, Jul 11, 2005 at 11:47:01AM -0700, Marcel Moolenaar wrote:
>> Given that registers are available when a value has been supplied,
>> it's logical to assume (a priori) that a register is unavailable
>> when no value has been supplied.
>
> You are talking about a completely different meaning of unavailable
> than Andrew was.  He's talking about unwinding, i.e. registers which
> have been modified but not saved by an intervening stack frame.

Ah, I see.  Wouldn't this apply only to caller-saved registers? And
wouldn't it be reasonable to mark them as unavailable unless proven
otherwise?

-- 
  Marcel Moolenaar         USPA: A-39004          marcel@xcllnt.net

Re: Invalid registers

[Andrew STUBBS]

On Mon, 11 Jul 2005 19:47:01 +0100, Marcel Moolenaar <marcel@cup.hp.com>  
wrote:
> Given that registers are available when a value has been supplied,
> it's logical to assume (a priori) that a register is unavailable
> when no value has been supplied. A register's valid "bit" allows
> for this since there are 2 states that indicate unavailability:
> One that indicates a temporary state (0) and one that indicates a
> permanent state (-1). The initial state of a register is the temporarily
> unavailable state, which triggers fetching the register from the
> target. The target can change the state to permanently unavailable
> or supply the value (it can also, theoretically at least, leave the
> state unmodified and not provide a value). Hence, the a priori
> assumption that registers are unavailable when no value has been
> supplied (i.e. when the valid "bit" is not 1) seems to yield good
> behaviour when implemented as such. I would say then that gdb knows
> when a value is not available.

Thanks, I did look at this before I posted, but I concluded that I was not  
what I was looking for. I mean, how would the target know what frame you  
were in?

I do not know what it means for a register to be invalid in the target.  
Might it be because some registers are not available when, for example,  
the FPU is disabled?

In any case, my target is always happy to supply registers.

Andrew Stubbs

Re: Invalid registers

[Marcel Moolenaar]

On Jul 12, 2005, at 9:13 AM, Andrew STUBBS wrote:

> On Mon, 11 Jul 2005 19:47:01 +0100, Marcel Moolenaar 
> <marcel@cup.hp.com> wrote:
>> Given that registers are available when a value has been supplied,
>> it's logical to assume (a priori) that a register is unavailable
>> when no value has been supplied. A register's valid "bit" allows
>> for this since there are 2 states that indicate unavailability:
>> One that indicates a temporary state (0) and one that indicates a
>> permanent state (-1). The initial state of a register is the 
>> temporarily
>> unavailable state, which triggers fetching the register from the
>> target. The target can change the state to permanently unavailable
>> or supply the value (it can also, theoretically at least, leave the
>> state unmodified and not provide a value). Hence, the a priori
>> assumption that registers are unavailable when no value has been
>> supplied (i.e. when the valid "bit" is not 1) seems to yield good
>> behaviour when implemented as such. I would say then that gdb knows
>> when a value is not available.
>
> Thanks, I did look at this before I posted, but I concluded that I was 
> not what I was looking for. I mean, how would the target know what 
> frame you were in?

You only ask the target about the current or interrupted state (i.e.
frame #0).  From that you unwind to the state of the frame in question.
I noticed that even in frame #0 all registers were displayed. Even if
I marked some of them as unavailable. This of course affects unwinding
as well. So, even though I misunderstood the context, the issues are
closely related.

> I do not know what it means for a register to be invalid in the 
> target. Might it be because some registers are not available when, for 
> example, the FPU is disabled?

Yes, that could be a possibility.  On ia64, for example, the number
of stacked registers is variable.  gdb currently displays all 96 of
them, even if the frame has only 3 stacked registers allocated.
Other examples include registers that are simply not exposed through
ptrace(2) or saved in core files. That is, the set of registers
available to gdb may vary between operating systems. It makes sense
for gdb to know about the superset, but it would be nice if it then
didn't output 0 values for registers that aren't available as that
may cause confusion.

BTW: this isn't a big deal, because you can debug your code anyway.
It's just (much) nicer to be able to represent reality better.

-- 
  Marcel Moolenaar         USPA: A-39004          marcel@xcllnt.net

Re: Invalid registers

[Andrew STUBBS]

On Mon, 11 Jul 2005 16:49:26 +0100, Daniel Jacobowitz <drow@false.org>  
wrote:
> On Mon, Jul 11, 2005 at 04:39:51PM +0100, Andrew STUBBS wrote:
>> Hi,
>>
>> I have been having a little trouble updating from GDB 5.3 to GDB 6.3.
>>
>> It used to be the case that GDB would report '*value not available*'  
>> (for
>> SH - I haven't checked other architectures) if the value of a register  
>> is
>> not known in the current stack frame. However, it no longer does this.
>> Since I assume it has not acquired some way to find out what that value
>> was, I also assume this is somehow broken.
>
> How's it supposed to know that the value is not available?  If you want
> to do this based on the standard call ABI, please take a look at the
> current callers of dwarf2_frame_set_init_reg.

Thank you. This has helped me find the right stuff to look at.

I do not think I actually want to use dwarf2_frame_set_init_reg. The  
compiler (GCC 3.4.3) produces CFI information which I think ought to be  
enough.

The function execute_cfa_program in dwarf2-frame.c appears to load all the  
relevant data (setting breakpoints in strategic places show this). If I  
use 'up' and 'info registers' I see the values change, which shows that  
the CFI data has been loaded (doesn't it?). It just appears that the 'how'  
field from the CFA is being ignored when the values are printed. Setting  
'how' via dwarf2_frame_set_init_reg is not ignored however. It must be  
being reset, or perhaps not copied in the first place.

Any clues?

Thanks

Andrew Stubbs

Re: Invalid registers

[Daniel Jacobowitz]

On Tue, Jul 12, 2005 at 05:04:41PM +0100, Andrew STUBBS wrote:
> Thank you. This has helped me find the right stuff to look at.
> 
> I do not think I actually want to use dwarf2_frame_set_init_reg. The  
> compiler (GCC 3.4.3) produces CFI information which I think ought to be  
> enough.
> 
> The function execute_cfa_program in dwarf2-frame.c appears to load all the  
> relevant data (setting breakpoints in strategic places show this). If I  
> use 'up' and 'info registers' I see the values change, which shows that  
> the CFI data has been loaded (doesn't it?). It just appears that the 'how'  
> field from the CFA is being ignored when the values are printed. Setting  
> 'how' via dwarf2_frame_set_init_reg is not ignored however. It must be  
> being reset, or perhaps not copied in the first place.
> 
> Any clues?

Sorry, not enough information - I'd need specifics.  GCC's CFI
generally does not represent call-clobbered registers; waste of space
for a runtime unwinder.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Invalid registers

[Andrew STUBBS]

On Tue, 12 Jul 2005 18:34:50 +0100, Daniel Jacobowitz <drow@false.org>  
wrote:
> Sorry, not enough information - I'd need specifics.  GCC's CFI
> generally does not represent call-clobbered registers; waste of space
> for a runtime unwinder.

Ok, after further investigation, here's what I'm seeing.

The default init_reg function, dwarf2_frame_default_init_reg, sets up the  
PC and stack pointer registers so that they do the right thing.  
Additionally, the CFI information describes how the R14 (frame pointer)  
and PR (saved PC) registers are saved to the stack.

With this setup, 'frame 1' followed by 'info all-registers' shows the  
correct values (I assume) for the four registers above, and (potentially)  
incorrect values for everything else.

So I set up a function, as follows, to tell it that anything is invalid,  
unless it knows otherwise:

sh_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum,
                             struct dwarf2_frame_state_reg *reg)
{
   /* Mark PC as destination for the return address.  */
   if (regnum == PC_REGNUM)
     reg->how = DWARF2_FRAME_REG_RA;

   /* Mark stack pointer set it to the call frame address.  */
   else if (regnum == SP_REGNUM)
     reg->how = DWARF2_FRAME_REG_CFA;

   /* Mark all other registers as invalid.
      Braindead, but ok for now.  */
   else
     reg->how = DWARF2_FRAME_REG_UNDEFINED;
}

With this function I get different wrong behaviour. Now I get all but PC  
and R15 (stack pointer) as '*value not available*'. I had expected that  
that the CFI would override the initialised values because it knows best  
(just because it is called 'init', not 'set), but neither R14 nor PR have  
their true values listed despite execute_cfa_program extracting a 'how'  
value of DWARF2_FRAME_REG_SAVED_OFFSET. Clearly this is not the case, but  
should it be?

Obviously the function above is overkill, in any case, because callee  
saved registers always have a useful value in them - either they have not  
changed or they have been saved and the CFI knows about it. I could fix  
that by just looking up exactly which they are and encoding it into the  
function above.

However, it is not clear to me what to do with caller save registers. If I  
just set them to undefined, as above, then they will never have a value,  
but are there sometimes saved values for those registers (saved by the  
caller) and cannot CFI describe this? In short, is it always the case that  
call clobblered registers are unavailable? I know the PR register is  
technically caller save, but has a CFI entry in my test program, but then  
in practice PR is really treated as callee save anyway. Is that just a  
special case?

Thanks

Andrew Stubbs

Re: Invalid registers

[Daniel Jacobowitz]

On Wed, Jul 13, 2005 at 03:44:10PM +0100, Andrew STUBBS wrote:
> With this function I get different wrong behaviour. Now I get all but PC  
> and R15 (stack pointer) as '*value not available*'. I had expected that  
> that the CFI would override the initialised values because it knows best  
> (just because it is called 'init', not 'set), but neither R14 nor PR have  
> their true values listed despite execute_cfa_program extracting a 'how'  
> value of DWARF2_FRAME_REG_SAVED_OFFSET. Clearly this is not the case, but  
> should it be?

Why isn't it?  Please debug this, since reading the code clearly
suggests it works as you expect.  See dwarf2_frame_cache.

> Obviously the function above is overkill, in any case, because callee  
> saved registers always have a useful value in them - either they have not  
> changed or they have been saved and the CFI knows about it. I could fix  
> that by just looking up exactly which they are and encoding it into the  
> function above.

Correct.

> However, it is not clear to me what to do with caller save registers. If I  
> just set them to undefined, as above, then they will never have a value,  
> but are there sometimes saved values for those registers (saved by the  
> caller) and cannot CFI describe this? In short, is it always the case that  

No, it can't.  CFI describes the state at the call instruction, from
the point of view of the called function.  It's not conceptually
impossible to describe caller saved registers, but no compiler I'm
familiar with does it...

> call clobblered registers are unavailable? I know the PR register is  

Only if they are clobbered.  That's why GDB defaults to showing them
anyway; it is often useful, although sometimes wrong.

> technically caller save, but has a CFI entry in my test program, but then  
> in practice PR is really treated as callee save anyway. Is that just a  
> special case?

I would need to see the CFI, sorry - I can't follow exactly what you
mean.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Invalid registers

[Andrew STUBBS]

On Wed, 13 Jul 2005 16:42:07 +0100, Daniel Jacobowitz <drow@false.org>  
wrote:

> On Wed, Jul 13, 2005 at 03:44:10PM +0100, Andrew STUBBS wrote:
>> With this function I get different wrong behaviour. Now I get all but PC
>> and R15 (stack pointer) as '*value not available*'. I had expected that
>> that the CFI would override the initialised values because it knows best
>> (just because it is called 'init', not 'set), but neither R14 nor PR  
>> have
>> their true values listed despite execute_cfa_program extracting a 'how'
>> value of DWARF2_FRAME_REG_SAVED_OFFSET. Clearly this is not the case,  
>> but
>> should it be?
>
> Why isn't it?  Please debug this, since reading the code clearly
> suggests it works as you expect.  See dwarf2_frame_cache.

I'll see what I can find.

>> I know the PR register is
>> technically caller save, but has a CFI entry in my test program, but  
>> then
>> in practice PR is really treated as callee save anyway. Is that just a
>> special case?
>
> I would need to see the CFI, sorry - I can't follow exactly what you
> mean.

The SH ABI lists the PR register (in which the PC is saved by a branch to  
subroutine) as caller save. This is true because a function has to save it  
before calling a subroutine. However, in practice it can be viewed as a  
callee save register because all non-leaf functions save it in the  
function prologue. GCC appears to be emitting CFI information for PR as if  
it was callee save.

You say that there should be no CFI for caller saved registers, so I'll  
take that as answering my question.

Thanks

Andrew Stubbs

Re: Invalid registers

[Daniel Jacobowitz]

On Wed, Jul 13, 2005 at 05:14:02PM +0100, Andrew STUBBS wrote:
> The SH ABI lists the PR register (in which the PC is saved by a branch to  
> subroutine) as caller save. This is true because a function has to save it  
> before calling a subroutine. However, in practice it can be viewed as a  
> callee save register because all non-leaf functions save it in the  
> function prologue. GCC appears to be emitting CFI information for PR as if  
> it was callee save.
> 
> You say that there should be no CFI for caller saved registers, so I'll  
> take that as answering my question.

Sorry, at some point you got me turned around with my own terminology. 
Let me try again, more coherently.

CFI describes saved registers.  It can describe any saved register;
typically, however, it only describes enough state to unwind to the
state as-of any call instruction, i.e. to describe any frame on the
stack.  At a call instruction there is still code in the caller to be
executed which will reload the caller saved registers; that code can be
freely scheduled, it is not part of the call sequence.  So typically it
is not described.  Those registers are dead at the call site and given
interesting values again later.

While the registers may be conceptually unavailable, the variables in
them are not - if your compiler emits good location lists, they'll
reflect the stack slots used.

So the value for PR we want to recover while unwinding is the value it
had "at the call site" - generally unavailable.  But we can figure out
what it was just after the call site, where the prologue will often
have saved it, and use that to determine where to unwind to.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Invalid registers

[Andrew STUBBS]

On Wed, 13 Jul 2005 16:42:07 +0100, Daniel Jacobowitz <drow@false.org>  
wrote:

> On Wed, Jul 13, 2005 at 03:44:10PM +0100, Andrew STUBBS wrote:
>> With this function I get different wrong behaviour. Now I get all but PC
>> and R15 (stack pointer) as '*value not available*'. I had expected that
>> that the CFI would override the initialised values because it knows best
>> (just because it is called 'init', not 'set), but neither R14 nor PR  
>> have
>> their true values listed despite execute_cfa_program extracting a 'how'
>> value of DWARF2_FRAME_REG_SAVED_OFFSET. Clearly this is not the case,  
>> but
>> should it be?
>
> Why isn't it?  Please debug this, since reading the code clearly
> suggests it works as you expect.  See dwarf2_frame_cache.

I think I have found the 'problem'.

It is working as it should, but it doesn't look like it at first sight.  
When I set a breakpoint on a function it breaks _before_ the callee save  
registers have been saved (this may be a mistake, I'm not sure yet). If I  
step into the function a little more then the CFI kicks in and it  
overrides the initial settings I put in.

What confused my is that there is more than one frame available at once  
(of course), and when debugging it is not always clear which one I am  
looking at, especially when it is typically the same set of registers  
being saved.

Thank you for all your help. Apologies for being thick.

Now onto the next issue ....

Andrew Stubbs

Re: Invalid registers

[Daniel Jacobowitz]

On Thu, Jul 14, 2005 at 10:33:25AM +0100, Andrew STUBBS wrote:
> It is working as it should, but it doesn't look like it at first sight.  
> When I set a breakpoint on a function it breaks _before_ the callee save  
> registers have been saved (this may be a mistake, I'm not sure yet). If I  

Yes - this is generally a mistake, either in the prologue analyzer or
in your compiler's generated line info.  But it isn't necessarily an
important mistake.

> step into the function a little more then the CFI kicks in and it  
> overrides the initial settings I put in.

Right.  This is a little unfortunate, but I don't know what we can do
about it - it seems unlikely to be worth the trouble.  FWIW, a compiler
_could_ generate sufficiently detailed CFI for this.

-- 
Daniel Jacobowitz
CodeSourcery, LLC