From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16224 invoked by alias); 10 Jul 2007 19:41:46 -0000 Received: (qmail 16216 invoked by uid 22791); 10 Jul 2007 19:41:45 -0000 X-Spam-Check-By: sourceware.org Received: from mail.artimi.com (HELO mail.artimi.com) (194.72.81.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Jul 2007 19:41:43 +0000 Received: from rainbow ([192.168.8.46]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jul 2007 20:41:41 +0100 From: "Dave Korn" To: "'Hadron'" , "'Nick Roberts'" Cc: "'Jim Blandy'" , "'Hadron'" , References: <87ejjhg137.fsf@gmail.com> <18066.47080.812496.129394@kahikatea.snap.net.nz> <87hcoc5uef.fsf@gmail.com> Subject: RE: argc - cant access memory Date: Tue, 10 Jul 2007 19:41:00 -0000 Message-ID: <00a401c7c32a$567046f0$2e08a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87hcoc5uef.fsf@gmail.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00080.txt.bz2 On 10 July 2007 13:13, Hadron wrote: > As for optimizing the arguments away, wouldn't this be the case for all > the lines referencing argc in the main()? But is this the typical > "error" for such a case? Ah, I've just recognised what's going on here, this is not optimisation, that's a red herring. > I get the message after stepping over the first line in main and then > when I get to line 3 (in main) then I get > > #0 main (argc=191860, argv=0xb7f49850) at hello.c:94 > > (94 is the line "glutInitWindowSize (250, 250);" in main) > > If you say this is normal behaviour then fine, but I haven't experienced > it before. I would be interested to hear if you get the same. This is normal behaviour. It's nothing to do with optimisation: it's just that gdb breakpoints at the very start of the function epilogue, but none of the arguments parameters are accessible in the expected places indicated by the debug info until after the epilogue has created the stack frame, etc. Try this with any function you like: set a breakpoint on the very first line - the one with the opening '{' of the function, run until you hit the breakpoint. You'll see nonsense in the locals and arguments. Now use the 'next' function to step over the opening brace - which amounts to stepping over the function epilogue - and suddenly all those variables will spring into being with their correct values. It's a cosmetic glitch that gdb fails to say something like "not in scope" before the prologue has completed. cheers, DaveK -- Can't think of a witty .sigline today....