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

[Pedro Alves <pedro_alves at portugalmail dot pt>]

Pierre Muller wrote:
>   I was rereading the thread:
> http://sourceware.org/ml/gdb-patches/2007-10/msg00361.html
>  but if I understood things correctly, it would mean
> that if your patch goes in, and I use the 
> 'start' command, I would end up
> past the call to __main.

(note that I've since split that patch
 into smaller parts -- the skip___main part
 is small, and really non-dependant on the rest.  I can
 post it if you find it useful for the discussion.)

>   This might be an annoying change for people 
> used, like me, to either 'step' or 'next'
> after 'start' depending on if they want to analyze
> what is going on in the startup code.

You can still place a breakpoint on __main then
if you want that -- but that depending on that
behaviour is depending on internal implementation details.
For instance, with a recent enough MinGW runtime, that won't
work, because __main is also called *before* reaching
main.

>   Thus, I am asking:
> Why do you consider this as broken?

Preciselly because I as a user find that is it suprising
that for my c++ global ctors to run after typing start,
I need to either 'step' or 'next'.  And I won't be
convinced that a less gdb savy user won't find it
surprising too.  If we can provide the illusion, then
why not?
(I'm not claiming my patch is best way to provide it,
I'm talking about the concept here.)

> Is it just because this is the reason of a lot of
> cygwin testsuite failures?

That too.

>   If this is the reason, I would propose another route
> to solve this:
>   Modify gdb.exp runto_main function
> so that if it ends up at a line
> containing only an open brace, it will 
> know that there is some implicit code
> that needs to be executed and just issue a 'next' command
> to reach the point that is reached directly in
> other systems.

I considered this too, but this it felt like a
workaround for something gdb should do itself.

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

>   The main problem is that the pattern used to figure out if 
> we are still in the function prologue is probably not optimal
> and requires that we do put the open brace alone on a separate
> line, but that seems to be always the case (at least for the main function)
> in all the test sources.
>   Is it a coding style requirement?

Not all.  Not the whole world is GNU:

> cd testsuite
> grep -rn "main" * | grep ")[ \t]*{"
gdb.base/call-ar-st.c:1146:int main ()  {
gdb.base/call-rt-st.c:696:int main ()  {
gdb.base/gdb1821.c:23:int main(void) { return 0; }
gdb.base/long_long.c:83:int main() {
gdb.base/step-test.c:23:int main () {
gdb.base/varargs.c:26:int main() {
gdb.cp/cplusfuncs.cc:66:int main () {
gdb.cp/hang1.C:3:int main (int argc, char **argv) { return 0; }
gdb.cp/bs15503.cc:60:int main() {
gdb.hp/gdb.defects/bs14602.c:6:int main () {
gdb.java/jprint.java:55:  public static void main(String[] args) {
gdb.threads/print-threads.c:12:int main() {
gdb.threads/schedlock.c:29:int main() {
gdb.threads/thread-specific.c:27:int main() {
gdb.threads/threadapply.c:31:int main() {
gdb.threads/watchthreads.c:31:int main() {
lib/gdb.exp:1284:    puts $f "int main() {"

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.

>   The global skip_function_prologue could be used for a
> more general approach, like if we test programs that have been
> compiled with profiling on.

But skipping the prologue and finding the first line of
a function is a job of gdb, why work around it in
the testsuite?  If you generalize this will be hiding
changes in that part of gdb.  If adding profile support
puts something in the prologue (like a call to mcount)
that brakes gdb's prologue analyzing and skipping, then
it should be fixed in gdb and/or in the debug info.

--
Pedro Alves