Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Joel Brobecker <brobecker@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA/RFC] New command: ``start''
Date: Thu, 20 May 2004 13:46:00 -0000	[thread overview]
Message-ID: <20040520134600.GA11705@nevyn.them.org> (raw)
In-Reply-To: <20040520010145.GQ10684@gnat.com>

On Wed, May 19, 2004 at 06:01:45PM -0700, Joel Brobecker wrote:
> Daniel,
> 
> On Wed, May 19, 2004 at 11:41:55AM -0400, Daniel Jacobowitz wrote:
> > On Wed, May 19, 2004 at 08:36:15AM -0700, Joel Brobecker wrote:
> > > So let's go for that route. How about:
> > >   1. I add the language-specific hook the way I designed it
> > >      in my last patch.
> > >   2. Use that hook in main_name() when the debug info didn't provide
> > >      the name of the main procedure.
> > >   3. Modify start_command to use main_name() instead of the language
> > >      hook.
> > > 
> > > Would that work for you?
> > 
> > That sounds good to me.
> 
> I was implementing this approach, with symtab.c caching the name_of_main
> so that we would compute it only once per executable loaded, but then
> just realized something that made me very uneasy.
> 
> Basically, because of the caching, we've transformed name_of_main into
> a random value, because it depends on the value of the current language
> at a certain random point in time. And that value will not be changed
> again until the user reloads his executable again (via exec-file).

You're right.  This is a problem.

> We could get rid of the caching mechanism, and recompute name_of_main
> everytime (unless found in the debug info), but I think that would be
> very costly, especially with graphical front-ends that have a tendency
> of asking for the callstack at every stop...

I don't think it would be costly.  However, I think it would be very
confusing!  Consider: we're in an Ada routine.  We backtrace.  This is
the main program, so the backtrace stops at this procedure.  We
single-step into a C subroutine and backtrace; now the backtrace goes
back to the Ada procedure and then back again further!

I'm having the same problem reviewing this that I did with
SYMBOL_SEARCH_NAME: namely, you're introducing interfaces that don't
exist in our Ada support files, without the Ada implementation of the
interface.  Could you show me what the Ada function for guessing the
name of main does?  I think the best approach may be to iterate over
the languages included in the object file, asking each of them whether
this language appears to contain a main procedure.  Or even to simply
skip the langhook complexity and just call an Ada find-main function!
For gcj I suspect we will just change the debug information.

-- 
Daniel Jacobowitz


  parent reply	other threads:[~2004-05-20 13:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-18  2:47 Joel Brobecker
2004-05-18  6:32 ` Eli Zaretskii
2004-05-18 17:05   ` Joel Brobecker
2004-05-18 18:42     ` Eli Zaretskii
2004-05-18 19:03       ` Andrew Cagney
2004-05-19  5:39         ` Eli Zaretskii
2004-05-18 19:22       ` Joel Brobecker
2004-05-18 21:47 ` Daniel Jacobowitz
2004-05-18 22:27   ` Joel Brobecker
2004-05-18 22:41     ` Daniel Jacobowitz
2004-05-19 15:36       ` Joel Brobecker
2004-05-19 15:42         ` Daniel Jacobowitz
2004-05-19 16:10           ` Joel Brobecker
2004-05-20  1:01           ` Joel Brobecker
2004-05-20  5:29             ` Eli Zaretskii
2004-05-20 13:46             ` Daniel Jacobowitz [this message]
2004-05-20 16:03               ` Joel Brobecker
2004-05-20 17:14                 ` Daniel Jacobowitz
2004-05-20 20:33                   ` Paul Gilliam
2004-05-20 22:12                   ` Joel Brobecker
2004-05-21  0:26                     ` Daniel Jacobowitz
2004-05-21  1:31                       ` Joel Brobecker
2004-05-24 22:24                         ` Daniel Jacobowitz
2004-05-24 23:57                           ` Joel Brobecker
2004-05-19 14:30 ` Andrew Cagney
2004-05-19 15:39   ` Joel Brobecker
2004-05-19 20:02     ` Eli Zaretskii
2004-05-21 18:57       ` Andrew Cagney
2004-05-18 19:30 Michael Elizabeth Chastain
2004-05-18 19:45 ` Joel Brobecker
2004-05-18 20:21 Michael Elizabeth Chastain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040520134600.GA11705@nevyn.them.org \
    --to=drow@false.org \
    --cc=brobecker@gnat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox