From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21313 invoked by alias); 5 Dec 2007 22:55:03 -0000 Received: (qmail 21304 invoked by uid 22791); 5 Dec 2007 22:55:02 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.191) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Dec 2007 22:54:54 +0000 Received: by nf-out-0910.google.com with SMTP id b11so3381816nfh for ; Wed, 05 Dec 2007 14:54:51 -0800 (PST) Received: by 10.78.160.4 with SMTP id i4mr1440901hue.1196895291488; Wed, 05 Dec 2007 14:54:51 -0800 (PST) Received: from ?88.210.66.24? ( [88.210.66.24]) by mx.google.com with ESMTPS id k10sm1004993nfh.2007.12.05.14.54.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Dec 2007 14:54:51 -0800 (PST) Message-ID: <47572C3C.70000@portugalmail.pt> Date: Wed, 05 Dec 2007 22:56:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Pierre Muller CC: gdb-patches@sourceware.org Subject: Re: [RFC] testsuite: Skip over function prologue in runto and runto_main References: <47112285.2080100@portugalmail.pt> <001601c83720$5a6ccca0$0f4665e0$@u-strasbg.fr> In-Reply-To: <001601c83720$5a6ccca0$0f4665e0$@u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00095.txt.bz2 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