This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: FRAME_ARGS_SKIP
- To: Jim Blandy <jimb at cygnus dot com>
- Subject: Re: FRAME_ARGS_SKIP
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 14 Jun 2001 22:48:30 -0400
- Cc: gdb at sources dot redhat dot com
- References: <20010614180846.92AAA5E9CB@zwingli.cygnus.com>
> 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