Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Pierre Muller" <muller@ics.u-strasbg.fr>
To: "'Pedro Alves'" <pedro_alves@portugalmail.pt>
Cc: <gdb-patches@sourceware.org>
Subject: RE: [RFC] testsuite: Skip over function prologue in runto and runto_main
Date: Thu, 06 Dec 2007 16:34:00 -0000	[thread overview]
Message-ID: <002a01c83824$dc461e20$94d25a60$@u-strasbg.fr> (raw)
In-Reply-To: <47572C3C.70000@portugalmail.pt>

> > Here is the proposed patch:
> >
> >   It basically defines two new globals variables in gdb.exp:
> > 1)  skip_function_prologue
> >   that should be "yes" if gdb should execute a 'next' statement
> > if after the 'runto' procedure it arrives at a line that contains
> > only an opening brace.
> >
> > 2)  skip_main_function_prologue
> >   Which does the same, but only within runto_main procedure.
> > This variable is set to "yes" if EXEEXT env is different from "".
> > But this is probably not the right condition.
> > I have no good idea how to set that variable, but
> > maybe setting it unconditionally would be OK too.
> >
> >
> 
> What problem is 1) trying to solve?

  It is mainly because runto_main is
calling runto procedure, and that the patterns
are only inside runto procedure.
  But as said, this would probably 
allow to skip implicit code that is not recognized as part of
the prologue.
  As programmer of the Free Pascal Compiler, I
know that there is quite some implicit code 
hidden inside the 'begin' pascal statement (equivalent of the C open brace),
like exception stack setup, win32 special call to avoid
stack faults for big local stack areas, implicit class
initialization...
  To handle this we would just need to replace the
open brace by a variable possibly named 'function_start_token'
defaulting to '{' but that would be changed into 'begin'
for pascal, and probably also for 'ada' or ''.
> Just a nit, but __main call is not really considered part
> of the prologue.  It's emitted as the first statement
> of the body of main.

  But this is the main problem here:
  many testsuite expect files do assume that
by using runto_main you arrive on the first 
explicit statement in the main function.

  Thus if the call to __main is implicit, we need to 
decide if gdb should place the breakpoint past
that implicit call, which is what your patch does,
but to me this is the same as saying that the call to main
is part of the prologue. But you just said
the opposite.

  My patch would rather be something like,
for the main function:
a call to __main is the first statement on
some targets, but we do not what to make any
differences between those targets and others
(which call __main before main, or not at all)
and thus we skip any implicit code,
which would be better found by the fact that
the open brace is the last part of the line where we stop.
  I think that the pattern that I used 
should also find lines that contain both the main and the open
brace; possible errors would be something like


main (int argc; char** argv) { if (argc >0) {
  ...

where my patch would go too far,
but that is probably easy to correct
with a pattern allowing only a single open brace.


  The call to mcount in case of profiling 
could be handled with the same logic, no?


  So finally the main question remains to 
decide whether the call to __main (in main) (or mcount in 
profiled function) should be considered as part of the prologue 
or handled a real statements, even though they are implicit.

  

Pierre



  reply	other threads:[~2007-12-06 16:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-13 20:26 [rfc] Teach i386 prologue reader about _alloca and __main Pedro Alves
2007-10-13 21:09 ` Daniel Jacobowitz
2007-10-13 23:20   ` Pedro Alves
2007-10-14 15:55     ` Daniel Jacobowitz
2007-10-13 21:14 ` Mark Kettenis
2007-10-14  2:24   ` Pedro Alves
2007-12-05 10:11 ` [RFC] testsuite: Skip over function prologue in runto and runto_main Pierre Muller
2007-12-05 22:56   ` Pedro Alves
2007-12-06 16:34     ` Pierre Muller [this message]
2007-12-06 17:07       ` 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='002a01c83824$dc461e20$94d25a60$@u-strasbg.fr' \
    --to=muller@ics.u-strasbg.fr \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro_alves@portugalmail.pt \
    /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