From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3055 invoked by alias); 13 Oct 2007 21:09:47 -0000 Received: (qmail 3046 invoked by uid 22791); 13 Oct 2007 21:09:47 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 Oct 2007 21:09:44 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id l9DL7RUE020658; Sat, 13 Oct 2007 23:07:27 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id l9DL7Rd4014026; Sat, 13 Oct 2007 23:07:27 +0200 (CEST) Date: Sat, 13 Oct 2007 21:14:00 -0000 Message-Id: <200710132107.l9DL7Rd4014026@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: pedro_alves@portugalmail.pt CC: gdb-patches@sourceware.org In-reply-to: <47112285.2080100@portugalmail.pt> (message from Pedro Alves on Sat, 13 Oct 2007 20:54:45 +0100) Subject: Re: [rfc] Teach i386 prologue reader about _alloca and __main References: <47112285.2080100@portugalmail.pt> 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-10/txt/msg00364.txt.bz2 > Date: Sat, 13 Oct 2007 20:54:45 +0100 > From: Pedro Alves > > Hi guys, > > This is a new take on solving the issue described here: > > http://www.sourceware.org/ml/gdb/2006-11/msg00140.html > > On a nutshell, breaking on main is broken on Cygwin, and > all targets where gcc emits a call to __main in main, > right after the prologue. __main is responsible for calling > the c++ constructors of global objects, and registering the > destructors of the same objects to run at exit. This call > is inserted on targets that don't have an .init section. Do I understand correctly that this is not really Cygwin specific, but done for all targets with executable formats that don't have a concept of constructors (like ELF with .init)? > There is another problem with the prologue analysing, which is visible > on i386 targets using stabs debug info on gcc >= 4.1.0. > > eg: > int main (int argc, char **argv) > { > > On stabs, the debugger only knows that argc is the first parameter to > the function and that its type is int. It is up to the debugger > to know how to extract it from the frame. > > Gcc >= 4.1 can put code in the prologue to realign the stack pointer. > In that case, the frame base will not be the same as the incoming args > address, so gdb prints garbage for the arguments: > > main (argc=2280856, argv=0x61006198) at main.c:8 This is why you added i386_frame_args_address() isn't it? I thought GCC would actually copy the arguments in that case, but apperently that doesn't happen (anymore). Perhaps I'm just mistaken though. It's probably best to seperate this bit form the __main/_alloca mess. > The __main call is only expected on targets that gdb knows it should > be there. A new gdbarch callback is introduced for it, and cygwin > registers it. Like Daniel said already, unless you expect this gdbarch callback to be necessary on other architectures besides i386/amd64 it's better to make this a function pointer in 'struct i386_tdep'. > The patch intruduces a few minsyms lookups, which I'm not sure we > can do without. It looks like the risk is high to get it wrong > otherwise. As long as they only happen on platforms that suffer from __main I don't care ;). > Comments? I'm not too happy about this. It adds a lot of complexity for something I think the compiler should emit proper debug information for. Did you raise the issue with the GCC people? What was their answer? I think the alloca analysis should only happen on targets that need it. I wonder why GCC needs to make a library call, where it seems simply touching every page would be enough. Also, in i386_frame_cache(), I'd make the comment about where to finding %ecx a bit more general. I can think of other reasons why that register might have been pushed onto the stack. Might as well seperate out that bit from the diff too.