* [patch/rfc] Switch to generic_func_frame_chain_valid()
@ 2002-06-01 15:20 Andrew Cagney
2002-06-02 10:18 ` Daniel Jacobowitz
2002-06-08 11:35 ` Andrew Cagney
0 siblings, 2 replies; 8+ messages in thread
From: Andrew Cagney @ 2002-06-01 15:20 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 251 bytes --]
Hello,
This finishes off (I think) the FRAME_CHAIN_VALID debate. It sets it to
generic_func_frame_chain_valid(). That function being tweaked to handle
both generic dummy frame and the old style frame cases.
I'll commit it in a few days.
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3463 bytes --]
2002-06-01 Andrew Cagney <ac131313@redhat.com>
* gdbarch.sh (FRAME_CHAIN_VALID): Set default to
generic_func_frame_chain_valid.
* gdbarch.h, gdbarch.c: Re-generate.
* blockframe.c (generic_func_frame_chain_valid): Only check
PC_IN_CALL_DUMMY when generic dummy frames. Don't worry about
passing FP to PC_IN_CALL_DUMMY.
Fix PR gdb/360.
Index: blockframe.c
===================================================================
RCS file: /cvs/src/src/gdb/blockframe.c,v
retrieving revision 1.28
diff -u -r1.28 blockframe.c
--- blockframe.c 1 Jun 2002 20:44:21 -0000 1.28
+++ blockframe.c 1 Jun 2002 22:11:11 -0000
@@ -1298,7 +1298,8 @@
int
generic_func_frame_chain_valid (CORE_ADDR fp, struct frame_info *fi)
{
- if (PC_IN_CALL_DUMMY ((fi)->pc, fp, fp))
+ if (USE_GENERIC_DUMMY_FRAMES
+ && PC_IN_CALL_DUMMY ((fi)->pc, 0, 0))
return 1; /* don't prune CALL_DUMMY frames */
else /* fall back to default algorithm (see frame.h) */
return (fp != 0
Index: gdbarch.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.c,v
retrieving revision 1.129
diff -u -r1.129 gdbarch.c
--- gdbarch.c 29 May 2002 16:39:54 -0000 1.129
+++ gdbarch.c 1 Jun 2002 22:11:28 -0000
@@ -522,7 +522,7 @@
current_gdbarch->remote_translate_xfer_address = generic_remote_translate_xfer_address;
current_gdbarch->frame_args_skip = -1;
current_gdbarch->frameless_function_invocation = generic_frameless_function_invocation_not;
- current_gdbarch->frame_chain_valid = func_frame_chain_valid;
+ current_gdbarch->frame_chain_valid = generic_func_frame_chain_valid;
current_gdbarch->extra_stack_alignment_needed = 1;
current_gdbarch->convert_from_func_ptr_addr = core_addr_identity;
current_gdbarch->addr_bits_remove = core_addr_identity;
Index: gdbarch.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.h,v
retrieving revision 1.96
diff -u -r1.96 gdbarch.h
--- gdbarch.h 29 May 2002 01:51:16 -0000 1.96
+++ gdbarch.h 1 Jun 2002 22:12:33 -0000
@@ -1888,7 +1887,7 @@
/* Default (function) for non- multi-arch platforms. */
#if (!GDB_MULTI_ARCH) && !defined (FRAME_CHAIN_VALID)
-#define FRAME_CHAIN_VALID(chain, thisframe) (func_frame_chain_valid (chain, thisframe))
+#define FRAME_CHAIN_VALID(chain, thisframe) (generic_func_frame_chain_valid (chain, thisframe))
#endif
typedef int (gdbarch_frame_chain_valid_ftype) (CORE_ADDR chain, struct frame_info *thisframe);
Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.140
diff -u -r1.140 gdbarch.sh
--- gdbarch.sh 29 May 2002 16:39:55 -0000 1.140
+++ gdbarch.sh 1 Jun 2002 22:12:37 -0000
@@ -567,7 +567,7 @@
# XXXX - both default and alternate frame_chain_valid functions are
# deprecated. New code should use dummy frames and one of the generic
# functions.
-f:2:FRAME_CHAIN_VALID:int:frame_chain_valid:CORE_ADDR chain, struct frame_info *thisframe:chain, thisframe:::func_frame_chain_valid::0
+f:2:FRAME_CHAIN_VALID:int:frame_chain_valid:CORE_ADDR chain, struct frame_info *thisframe:chain, thisframe:::generic_func_frame_chain_valid::0
f:2:FRAME_SAVED_PC:CORE_ADDR:frame_saved_pc:struct frame_info *fi:fi::0:0
f:2:FRAME_ARGS_ADDRESS:CORE_ADDR:frame_args_address:struct frame_info *fi:fi::0:0
f:2:FRAME_LOCALS_ADDRESS:CORE_ADDR:frame_locals_address:struct frame_info *fi:fi::0:0
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [patch/rfc] Switch to generic_func_frame_chain_valid()
2002-06-01 15:20 [patch/rfc] Switch to generic_func_frame_chain_valid() Andrew Cagney
@ 2002-06-02 10:18 ` Daniel Jacobowitz
2002-06-03 6:29 ` Andrew Cagney
2002-06-08 11:35 ` Andrew Cagney
1 sibling, 1 reply; 8+ messages in thread
From: Daniel Jacobowitz @ 2002-06-02 10:18 UTC (permalink / raw)
To: gdb-patches
On Sat, Jun 01, 2002 at 06:20:22PM -0400, Andrew Cagney wrote:
> Hello,
>
> This finishes off (I think) the FRAME_CHAIN_VALID debate. It sets it to
> generic_func_frame_chain_valid(). That function being tweaked to handle
> both generic dummy frame and the old style frame cases.
>
> I'll commit it in a few days.
>
> Andrew
After this goes in, can we start switching existing targets? That
seemed to be the real point of debate - file_frame_chain_valid versus
func_frame_chain_valid. With the addition of a 'set' variable for
people who prefer the file_frame_chain_valid behavior, I don't see any
reason not to.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch/rfc] Switch to generic_func_frame_chain_valid()
2002-06-02 10:18 ` Daniel Jacobowitz
@ 2002-06-03 6:29 ` Andrew Cagney
2002-06-03 11:05 ` Michael Snyder
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2002-06-03 6:29 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
> On Sat, Jun 01, 2002 at 06:20:22PM -0400, Andrew Cagney wrote:
>
>> Hello,
>>
>> This finishes off (I think) the FRAME_CHAIN_VALID debate. It sets it to
>> generic_func_frame_chain_valid(). That function being tweaked to handle
>> both generic dummy frame and the old style frame cases.
>>
>> I'll commit it in a few days.
>>
>> Andrew
>
>
> After this goes in, can we start switching existing targets? That
> seemed to be the real point of debate - file_frame_chain_valid versus
> func_frame_chain_valid. With the addition of a 'set' variable for
> people who prefer the file_frame_chain_valid behavior, I don't see any
> reason not to.
For natives (hmm, need a new name - UNIX like targets?) I think
definitly and asap. For more embedded targets, yes, with set - do any
targets have custom frame-chain functions?
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch/rfc] Switch to generic_func_frame_chain_valid()
2002-06-03 6:29 ` Andrew Cagney
@ 2002-06-03 11:05 ` Michael Snyder
2002-06-03 11:13 ` Daniel Jacobowitz
0 siblings, 1 reply; 8+ messages in thread
From: Michael Snyder @ 2002-06-03 11:05 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Daniel Jacobowitz, gdb-patches
Andrew Cagney wrote:
>
> > On Sat, Jun 01, 2002 at 06:20:22PM -0400, Andrew Cagney wrote:
> >
> >> Hello,
> >>
> >> This finishes off (I think) the FRAME_CHAIN_VALID debate. It sets it to
> >> generic_func_frame_chain_valid(). That function being tweaked to handle
> >> both generic dummy frame and the old style frame cases.
> >>
> >> I'll commit it in a few days.
> >>
> >> Andrew
> >
> >
> > After this goes in, can we start switching existing targets? That
> > seemed to be the real point of debate - file_frame_chain_valid versus
> > func_frame_chain_valid. With the addition of a 'set' variable for
> > people who prefer the file_frame_chain_valid behavior, I don't see any
> > reason not to.
>
> For natives (hmm, need a new name - UNIX like targets?) I think
> definitly and asap. For more embedded targets, yes, with set - do any
> targets have custom frame-chain functions?
Yes, many. Did you mean "custom frame-chain-valid functions"?
Yes, I believe there are some of those too.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch/rfc] Switch to generic_func_frame_chain_valid()
2002-06-03 11:05 ` Michael Snyder
@ 2002-06-03 11:13 ` Daniel Jacobowitz
2002-06-03 11:49 ` Andrew Cagney
0 siblings, 1 reply; 8+ messages in thread
From: Daniel Jacobowitz @ 2002-06-03 11:13 UTC (permalink / raw)
To: Michael Snyder; +Cc: Andrew Cagney, gdb-patches
On Mon, Jun 03, 2002 at 10:50:47AM -0700, Michael Snyder wrote:
> Andrew Cagney wrote:
> >
> > > On Sat, Jun 01, 2002 at 06:20:22PM -0400, Andrew Cagney wrote:
> > >
> > >> Hello,
> > >>
> > >> This finishes off (I think) the FRAME_CHAIN_VALID debate. It sets it to
> > >> generic_func_frame_chain_valid(). That function being tweaked to handle
> > >> both generic dummy frame and the old style frame cases.
> > >>
> > >> I'll commit it in a few days.
> > >>
> > >> Andrew
> > >
> > >
> > > After this goes in, can we start switching existing targets? That
> > > seemed to be the real point of debate - file_frame_chain_valid versus
> > > func_frame_chain_valid. With the addition of a 'set' variable for
> > > people who prefer the file_frame_chain_valid behavior, I don't see any
> > > reason not to.
> >
> > For natives (hmm, need a new name - UNIX like targets?) I think
> > definitly and asap. For more embedded targets, yes, with set - do any
> > targets have custom frame-chain functions?
>
> Yes, many. Did you mean "custom frame-chain-valid functions"?
> Yes, I believe there are some of those too.
Assuming Andrew meant custom f-c-valid functions, then there are
several; all of them just add additional restrictions on the PC instead
of taking away. So I will update them to call the generic function
after they perform their additional checks, instead of duplicating.
Sound good?
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch/rfc] Switch to generic_func_frame_chain_valid()
2002-06-03 11:13 ` Daniel Jacobowitz
@ 2002-06-03 11:49 ` Andrew Cagney
2002-06-03 12:11 ` Daniel Jacobowitz
0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2002-06-03 11:49 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Michael Snyder, gdb-patches
>
> Assuming Andrew meant custom f-c-valid functions, then there are
> several; all of them just add additional restrictions on the PC instead
> of taking away. So I will update them to call the generic function
> after they perform their additional checks, instead of duplicating.
> Sound good?
Yes.
Hmm, or the reverse - have a generic frame_chain_valid() call a custom
one if/when one is present. That way, we don't rely on the
per-architecture variant remembering to also call the generic one.
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch/rfc] Switch to generic_func_frame_chain_valid()
2002-06-03 11:49 ` Andrew Cagney
@ 2002-06-03 12:11 ` Daniel Jacobowitz
0 siblings, 0 replies; 8+ messages in thread
From: Daniel Jacobowitz @ 2002-06-03 12:11 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Michael Snyder, gdb-patches
On Mon, Jun 03, 2002 at 02:49:19PM -0400, Andrew Cagney wrote:
> >
> >Assuming Andrew meant custom f-c-valid functions, then there are
> >several; all of them just add additional restrictions on the PC instead
> >of taking away. So I will update them to call the generic function
> >after they perform their additional checks, instead of duplicating.
> >Sound good?
>
> Yes.
>
> Hmm, or the reverse - have a generic frame_chain_valid() call a custom
> one if/when one is present. That way, we don't rely on the
> per-architecture variant remembering to also call the generic one.
And we can kill a macro that way, too. Sounds good.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [patch/rfc] Switch to generic_func_frame_chain_valid()
2002-06-01 15:20 [patch/rfc] Switch to generic_func_frame_chain_valid() Andrew Cagney
2002-06-02 10:18 ` Daniel Jacobowitz
@ 2002-06-08 11:35 ` Andrew Cagney
1 sibling, 0 replies; 8+ messages in thread
From: Andrew Cagney @ 2002-06-08 11:35 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb-patches
> 2002-06-01 Andrew Cagney <ac131313@redhat.com>
>
> * gdbarch.sh (FRAME_CHAIN_VALID): Set default to
> generic_func_frame_chain_valid.
> * gdbarch.h, gdbarch.c: Re-generate.
> * blockframe.c (generic_func_frame_chain_valid): Only check
> PC_IN_CALL_DUMMY when generic dummy frames. Don't worry about
> passing FP to PC_IN_CALL_DUMMY.
> Fix PR gdb/360.
I've checked this in.
Can I strongly encourage architecture maintainers to no longer set
FRAME_CHAIN_VALID and instead just let the architecture vector pick up
the default.
Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-06-08 18:35 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-01 15:20 [patch/rfc] Switch to generic_func_frame_chain_valid() Andrew Cagney
2002-06-02 10:18 ` Daniel Jacobowitz
2002-06-03 6:29 ` Andrew Cagney
2002-06-03 11:05 ` Michael Snyder
2002-06-03 11:13 ` Daniel Jacobowitz
2002-06-03 11:49 ` Andrew Cagney
2002-06-03 12:11 ` Daniel Jacobowitz
2002-06-08 11:35 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox