From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9844 invoked by alias); 28 Dec 2007 21:40:51 -0000 Received: (qmail 9836 invoked by uid 22791); 28 Dec 2007 21:40:51 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.188) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Dec 2007 21:40:45 +0000 Received: by nf-out-0910.google.com with SMTP id b11so315437nfh.48 for ; Fri, 28 Dec 2007 13:40:42 -0800 (PST) Received: by 10.78.188.10 with SMTP id l10mr12133545huf.14.1198878041572; Fri, 28 Dec 2007 13:40:41 -0800 (PST) Received: from ?88.210.76.48? ( [88.210.76.48]) by mx.google.com with ESMTPS id i3sm11812154nfh.28.2007.12.28.13.40.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Dec 2007 13:40:41 -0800 (PST) Message-ID: <47756D52.7010208@portugalmail.pt> Date: Fri, 28 Dec 2007 22:36: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: Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: [i386/stabs] Arguments of main on gcc >= 4.1 References: <47503C57.6010308@portugalmail.pt> <20071203182540.GB14306@adacore.com> <20071217004444.GA14356@caradoc.them.org> <20071217041159.GB9022@adacore.com> <20071217133121.GA23586@caradoc.them.org> <20071217142204.GI9022@adacore.com> <47744F3A.50005@portugalmail.pt> <20071228132203.GF24450@adacore.com> In-Reply-To: <20071228132203.GF24450@adacore.com> 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/msg00440.txt.bz2 Joel Brobecker wrote: > >>> I wonder how this all works if GCC < 4.1 is being used. >>> >> Gcc 3.4.4-cygwin works ok and doesn't need this patch. > > My concern at this point is whether GDB still works in this case > after you applied your patch. Unless GCC 3.4.4 doesn't emit the > stack-alignment code, it should no longer work... The questions > at this point are: Can we support both conventions? Do we even > want to? > gcc 3.4.4 doesn't emit the stack-alignment code. Unless the comments in i386-tdep.c are wrong, any gcc < 4.1 doesn't emit the stack-alignment code, which makes them immune to the patch. I did regtest the patch on Cygwin. > The fact that this has nobody before you reported that this is > broken since 4.1 shows that this is probably not an extremely > important issue. I've seen this reported at the mingw-users@ list with the new gcc4.2 binaries. As you know, mingw support wasn't in the FSF tree, so problems seen on mingw weren't being reported here. But sure, this isn't certainly my priority ;-) >> I see some movement at gcc@/gcc-patches@ about changing the stack >> alignment scheme on i386. That may be perfect. If we get the debug >> output fixed in the same release the prologue code changes, all will >> be fine. > > OK, so I will consider that this thread is currently on hold, pending > discussions in GCC. > Even if gcc debug info isn't fixed, there will be several gcc releases with the problem and (pending confirmation), no release with stack alignment without the problem. I'll try to break the patch further -- the setup for the workaround is mostly bugfixing, and I'll come back to the workaround later on if I'm still using a stabs outputting compiler by then :-) -- Pedro Alves