Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* RFC: dummy.[hc] and ``struct dummy''
@ 2002-09-26 15:47 Andrew Cagney
  2002-09-27 10:12 ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2002-09-26 15:47 UTC (permalink / raw)
  To: gdb

Hello,

I'd like to float the idea of moving all the generic dummy frame code 
into a new file dummy.[hc].

Things like hand_function_call() would then use a ``struct dummy'' that 
contains the information for the dummy frame currently being 
constructed.  That way the current global top-of-dummy stack assumption 
is removed.

This should also make it simplier/easier to do things like make what is 
currently a single global dummy frame stack part of the ``thread_info'' 
object.  (Figuring out why one would want to do this is left as an 
exercise for the reader.  LiamS, GraceS and I stumbled across this 
think-o :-).

Andrew


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: RFC: dummy.[hc] and ``struct dummy''
  2002-09-26 15:47 RFC: dummy.[hc] and ``struct dummy'' Andrew Cagney
@ 2002-09-27 10:12 ` Eli Zaretskii
  2002-09-27 11:20   ` Andrew Cagney
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2002-09-27 10:12 UTC (permalink / raw)
  To: ac131313; +Cc: gdb

> Date: Thu, 26 Sep 2002 18:47:11 -0400
> From: Andrew Cagney <ac131313@redhat.com>
> 
> I'd like to float the idea of moving all the generic dummy frame code 
> into a new file dummy.[hc].

Yes, but I'd suggest to call the files something other than dummy.*,
lest someone thinks they are junk ;-)


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: RFC: dummy.[hc] and ``struct dummy''
  2002-09-27 10:12 ` Eli Zaretskii
@ 2002-09-27 11:20   ` Andrew Cagney
  2002-09-27 11:21     ` Daniel Jacobowitz
  0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2002-09-27 11:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gdb

>> Date: Thu, 26 Sep 2002 18:47:11 -0400
>> From: Andrew Cagney <ac131313@redhat.com>
>> 
>> I'd like to float the idea of moving all the generic dummy frame code 
>> into a new file dummy.[hc].
> 
> 
> Yes, but I'd suggest to call the files something other than dummy.*,
> lest someone thinks they are junk ;-)

But then I can't have a function called ``dummy_spit()'' (OZ? expression 
for blowing one's fuse).

More seriously, I'm struggling for a better name: ``generic'' ``gdf'' 
``dummy-frame'', ...  I guess the last one?

Andrew



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: RFC: dummy.[hc] and ``struct dummy''
  2002-09-27 11:20   ` Andrew Cagney
@ 2002-09-27 11:21     ` Daniel Jacobowitz
  2002-09-27 11:38       ` Elena Zannoni
  0 siblings, 1 reply; 8+ messages in thread
From: Daniel Jacobowitz @ 2002-09-27 11:21 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: Eli Zaretskii, gdb

On Fri, Sep 27, 2002 at 02:20:30PM -0400, Andrew Cagney wrote:
> >>Date: Thu, 26 Sep 2002 18:47:11 -0400
> >>From: Andrew Cagney <ac131313@redhat.com>
> >>
> >>I'd like to float the idea of moving all the generic dummy frame code 
> >>into a new file dummy.[hc].
> >
> >
> >Yes, but I'd suggest to call the files something other than dummy.*,
> >lest someone thinks they are junk ;-)
> 
> But then I can't have a function called ``dummy_spit()'' (OZ? expression 
> for blowing one's fuse).
> 
> More seriously, I'm struggling for a better name: ``generic'' ``gdf'' 
> ``dummy-frame'', ...  I guess the last one?

I think dummy-frame works well.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: RFC: dummy.[hc] and ``struct dummy''
  2002-09-27 11:21     ` Daniel Jacobowitz
@ 2002-09-27 11:38       ` Elena Zannoni
  2002-09-27 11:59         ` Kevin Buettner
  0 siblings, 1 reply; 8+ messages in thread
From: Elena Zannoni @ 2002-09-27 11:38 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Andrew Cagney, Eli Zaretskii, gdb

Daniel Jacobowitz writes:
 > On Fri, Sep 27, 2002 at 02:20:30PM -0400, Andrew Cagney wrote:
 > > >>Date: Thu, 26 Sep 2002 18:47:11 -0400
 > > >>From: Andrew Cagney <ac131313@redhat.com>
 > > >>
 > > >>I'd like to float the idea of moving all the generic dummy frame code 
 > > >>into a new file dummy.[hc].
 > > >
 > > >
 > > >Yes, but I'd suggest to call the files something other than dummy.*,
 > > >lest someone thinks they are junk ;-)
 > > 
 > > But then I can't have a function called ``dummy_spit()'' (OZ? expression 
 > > for blowing one's fuse).
 > > 
 > > More seriously, I'm struggling for a better name: ``generic'' ``gdf'' 
 > > ``dummy-frame'', ...  I guess the last one?
 > 
 > I think dummy-frame works well.
 > 

infcall.[ch] ? (which goes with infcmd.c)

Elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: RFC: dummy.[hc] and ``struct dummy''
  2002-09-27 11:38       ` Elena Zannoni
@ 2002-09-27 11:59         ` Kevin Buettner
  2002-09-27 12:07           ` Andrew Cagney
  0 siblings, 1 reply; 8+ messages in thread
From: Kevin Buettner @ 2002-09-27 11:59 UTC (permalink / raw)
  To: Elena Zannoni, Daniel Jacobowitz; +Cc: Andrew Cagney, Eli Zaretskii, gdb

On Sep 27,  2:35pm, Elena Zannoni wrote:

>  > I think dummy-frame works well.
> 
> infcall.[ch] ? (which goes with infcmd.c)

I like this one.

I don't mind dummy-frame.[hc] either, but it's not 8.3 compliant.

Kevin


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: RFC: dummy.[hc] and ``struct dummy''
  2002-09-27 11:59         ` Kevin Buettner
@ 2002-09-27 12:07           ` Andrew Cagney
  2002-09-27 12:15             ` Elena Zannoni
  0 siblings, 1 reply; 8+ messages in thread
From: Andrew Cagney @ 2002-09-27 12:07 UTC (permalink / raw)
  To: Kevin Buettner; +Cc: Elena Zannoni, Daniel Jacobowitz, Eli Zaretskii, gdb

> On Sep 27,  2:35pm, Elena Zannoni wrote:
> 
> 
>>  > I think dummy-frame works well.
>> 
>> infcall.[ch] ? (which goes with infcmd.c)

For hand_function_call() et.al. (which I can never find 'cos it is 
hidden in valops.c)?  Ok.

For dummy-frame.[ch] I'm thinking of just the ``struct dummy_frame'' 
object code found in blockframe.c.

> I like this one.
> 
> I don't mind dummy-frame.[hc] either, but it's not 8.3 compliant.

It's ok.  It will be reduced to: dummy-fr.[ch].

Andrew



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: RFC: dummy.[hc] and ``struct dummy''
  2002-09-27 12:07           ` Andrew Cagney
@ 2002-09-27 12:15             ` Elena Zannoni
  0 siblings, 0 replies; 8+ messages in thread
From: Elena Zannoni @ 2002-09-27 12:15 UTC (permalink / raw)
  To: Andrew Cagney
  Cc: Kevin Buettner, Elena Zannoni, Daniel Jacobowitz, Eli Zaretskii, gdb

Andrew Cagney writes:
 > > On Sep 27,  2:35pm, Elena Zannoni wrote:
 > > 
 > > 
 > >>  > I think dummy-frame works well.
 > >> 
 > >> infcall.[ch] ? (which goes with infcmd.c)
 > 
 > For hand_function_call() et.al. (which I can never find 'cos it is 
 > hidden in valops.c)?  Ok.
 > 
 > For dummy-frame.[ch] I'm thinking of just the ``struct dummy_frame'' 
 > object code found in blockframe.c.
 > 
 > > I like this one.
 > > 
 > > I don't mind dummy-frame.[hc] either, but it's not 8.3 compliant.
 > 
 > It's ok.  It will be reduced to: dummy-fr.[ch].
 > 

Fine. Are you being politically correct towards French gdb users though? :-)

Elena


 > Andrew
 > 


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2002-09-27 19:15 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-26 15:47 RFC: dummy.[hc] and ``struct dummy'' Andrew Cagney
2002-09-27 10:12 ` Eli Zaretskii
2002-09-27 11:20   ` Andrew Cagney
2002-09-27 11:21     ` Daniel Jacobowitz
2002-09-27 11:38       ` Elena Zannoni
2002-09-27 11:59         ` Kevin Buettner
2002-09-27 12:07           ` Andrew Cagney
2002-09-27 12:15             ` Elena Zannoni

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox