FRAME_ARGS_SKIP

FRAME_ARGS_SKIP

[Jim Blandy]

Here's the entry from gdbarch.sh for FRAME_ARGS_SKIP:

v:2:FRAME_ARGS_SKIP:CORE_ADDR:frame_args_skip::::0:-1

This sets 0 as the static default, -1 as the predefault, and specifies
no postdefault.  If I'm reading gdbarch.sh correctly, this means that:

- we use 0 as the value in the dummy gdbarch object we use during
  startup, and

- we set this field to -1 in a newly allocated gdbarch object, and we
  report an internal error if we notice later that it still has this
  value.

If I add a postdefault, then instead of getting an internal error when
it's not initialized, we'll just drop in the postdefault value.

Is that correct?

This field should be zero for almost every architecture.  Would anyone
mind if I added a postdefault of zero?

Re: FRAME_ARGS_SKIP

[Andrew Cagney]

> Here's the entry from gdbarch.sh for FRAME_ARGS_SKIP:
> 
> v:2:FRAME_ARGS_SKIP:CORE_ADDR:frame_args_skip::::0:-1
> 
> This sets 0 as the static default, -1 as the predefault, and specifies
> no postdefault. If I'm reading gdbarch.sh correctly, this means that:


gdbarch.log (generated) should confirm this:


> - we use 0 as the value in the dummy gdbarch object we use during
> startup, and


Just FYI, that value was chosen strictly on the basis that it didn't 
appear to make GDB dump core during initialization.


> - we set this field to -1 in a newly allocated gdbarch object, and we
> report an internal error if we notice later that it still has this
> value.
> 
> If I add a postdefault, then instead of getting an internal error when
> it's not initialized, we'll just drop in the postdefault value.
> 
> Is that correct?


Yes.  It is also possible to make the pre-default zero and gag the error 
checking.


> This field should be zero for almost every architecture. Would anyone
> mind if I added a postdefault of zero?


Now that is a US$64 question (rougly AUD$64,000,000).

The strategy, when converting a macro to multi-arch, has been to 
preserve existing behavour.  If, pre-multi-arch, not defining a macro 
caused compiler errors, post- multi-arch it triggered an internal error.

If someone wants to go back and change a variable, after the event, 
then, mostly I'm not worried.  I'd just discourage it when there are 
more complex initialization dependencies such as for the dummy frame.

	Andrew

Re: FRAME_ARGS_SKIP

[Andrew Cagney]

Is your target pure multi-arch?  The gdbarch code does many many more 
startup checks on such targets.

	Andrew

Re: FRAME_ARGS_SKIP

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:

> 
> Is your target pure multi-arch?  The gdbarch code does many many more 
> startup checks on such targets.
> 
> 	Andrew

The complete contents of its tm-*.h file are:

/* This target uses an architecture vector exclusively.  */

#define GDB_MULTI_ARCH 1


So I'm guessing that should be GDB_MULTI_ARCH should actually be set
to GDB_MULTI_ARCH_PURE.  Is that right?

Re: FRAME_ARGS_SKIP

[Andrew Cagney]

> Is your target pure multi-arch?  The gdbarch code does many many more 
>> startup checks on such targets.
>> 
>> Andrew
> 
> 
> The complete contents of its tm-*.h file are:
> 
> /* This target uses an architecture vector exclusively.  */
> 
> #define GDB_MULTI_ARCH 1
> 
> 
> So I'm guessing that should be GDB_MULTI_ARCH should actually be set
> to GDB_MULTI_ARCH_PURE.  Is that right?


In that case you don't even need a tm.h. Instead tweek the end of 
configure.tgt so that it is something like the m68hc11.

	Andrew