From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: FRAME_ARGS_SKIP Date: Fri, 15 Jun 2001 00:10:00 -0000 Message-id: <3B29777E.6030401@cygnus.com> References: <20010614180846.92AAA5E9CB@zwingli.cygnus.com> X-SW-Source: 2001-06/msg00135.html > 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