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
next prev parent 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