From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28027 invoked by alias); 13 Oct 2007 23:20:40 -0000 Received: (qmail 28014 invoked by uid 22791); 13 Oct 2007 23:20:39 -0000 X-Spam-Check-By: sourceware.org Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.186) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 Oct 2007 23:20:37 +0000 Received: by fk-out-0910.google.com with SMTP id 26so1177975fkx for ; Sat, 13 Oct 2007 16:20:34 -0700 (PDT) Received: by 10.82.154.12 with SMTP id b12mr9183671bue.1192317634002; Sat, 13 Oct 2007 16:20:34 -0700 (PDT) Received: from ?78.130.34.112? ( [78.130.34.112]) by mx.google.com with ESMTPS id c14sm3084350nfi.2007.10.13.16.20.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Oct 2007 16:20:32 -0700 (PDT) Message-ID: <4711528C.60300@portugalmail.pt> Date: Sun, 14 Oct 2007 02:24:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Mark Kettenis CC: gdb-patches@sourceware.org Subject: Re: [rfc] Teach i386 prologue reader about _alloca and __main References: <47112285.2080100@portugalmail.pt> <200710132107.l9DL7Rd4014026@brahms.sibelius.xs4all.nl> In-Reply-To: <200710132107.l9DL7Rd4014026@brahms.sibelius.xs4all.nl> 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-10/txt/msg00366.txt.bz2 Mark Kettenis wrote: > > 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)? > Correct. >> 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. > Yes, that's why I added it. Humm, I'll have to try it out on another target to see if its a Cygwin specific gcc problem. > It's probably best to seperate this bit form the __main/_alloca mess. > Will do. >> 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 can't say I am happy either. I'll see if I can simplify it a bit, by only caring about -O0. I did raise it with GCC almost a year ago, in the form of a patch: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00633.html Got no replies, but then again, I never pinged it. We have to live with current compilers, though. > 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. > Dunno. The MSFT version of __chkstk supposedly compares the amount of stack space a function requires with the amount the stack space available, specified in the EXE header, and I guess specified on thread creation. http://support.microsoft.com/?scid=kb%3Ben-us%3B100775&x=10&y=10 gcc's version doesn't, so, it looks like work waiting for a volunteer. > 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. > Will do. Thanks. Cheers, Pedro Alves