Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Petr Sorfa <petrs@caldera.com>
Cc: "gdb-patches@sources.redhat.com" <gdb-patches@sources.redhat.com>
Subject: Re: [PATCH] DW_AT_calling_convention support REV 2
Date: Wed, 10 Jul 2002 12:41:00 -0000	[thread overview]
Message-ID: <20020710193458.GA28939@nevyn.them.org> (raw)
In-Reply-To: <3D2C8D8C.E5127E28@caldera.com>

On Wed, Jul 10, 2002 at 03:39:56PM -0400, Petr Sorfa wrote:
> Hi Daniel,
> 
> > > Revised patch for supporting DW_AT_calling_convention. This helps GDB
> > > identify the "main" program for languages that do not have a starting
> > > subroutine called "main". It adds a new API set for keeping track of the
> > > symbol associated with "main". Note that there are 3 checks for
> > > DW_AT_calling_convention. They are all necessary as they are detected at
> > > different times when processing program debug information.
> > 
> > I wasn't quite clear... there's one thing that should be different.
> > 
> > > + /* Determine whether the symbol passed is equivalent to
> > > +    the ``main'' symbol. Returns 0 if not or if there is no ``main''
> > > +    symbol set. */
> > > + int
> > > + is_main_symbol (struct symbol *check_symbol)
> > > + {
> > > +   return (check_symbol == NULL ? 0 : symbol_of_main == check_symbol);
> > > + }
> > >
> > >   void
> > >   _initialize_symtab (void)
> > 
> > I was thinking like:
> > 
> > int
> > is_main_symbol (struct symbol *check_symbol)
> > {
> >   if (symbol_of_main && symbol_of_main == check_symbol)
> >     return 1;
> >   else if (strcmp (SYMBOL_NAME (check_symbol), get_main_name ()) == 0)
> >     return 1;
> >   return 0;
> > }
> Good, I agree, that makes it more generic. Need to check for
> check_symbol for NULL as this might tank GDB at the second if.

Why should NULL be a legitimate argument?  Calling the function without
a symbol is useless...

> > And then change all callers of get_main_name () to use this.
> > 
> > (Note that this requires being careful if symbol_of_main gets
> > unloaded and we load a C program afterwards!)
> > 
> > Make sense?  Sound reasonable?
> Um, you've lost me. There is no get_main_name() function, do you mean
> get_main_symbol() or main_name()? I still not sure what the callers of
> the function should do.

main_name(), I assume.  Basically I would like everywhere that
currently checks by a strcmp/STREQ with main_name() to use
is_main_symbol () instead, etc.  Things that call lookup_symbol on
main_name() should just use get_main_symbol () if possible.  Then
set_main_name () could include calling lookup_symbol(main_name()), so
that get_main_symbol would always be valid, etc....

> Although, I do agree that the patch should catch unloading the
> main_symbol, but how?

I'm not sure :(  Is there a hook for when object files are unloaded?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2002-07-10 19:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-10 11:41 Petr Sorfa
2002-07-10 11:47 ` Daniel Jacobowitz
2002-07-10 12:32   ` Petr Sorfa
2002-07-10 12:41     ` Daniel Jacobowitz [this message]
2002-07-10 14:06       ` Petr Sorfa
2002-07-11  8:07       ` Petr Sorfa
2002-07-11  9:22         ` Daniel Jacobowitz

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=20020710193458.GA28939@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=petrs@caldera.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