This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [RFC] testsuite: Skip over function prologue in runto and runto_main


> > 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]