Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [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