From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4421 invoked by alias); 13 Oct 2007 21:14:44 -0000 Received: (qmail 4412 invoked by uid 22791); 13 Oct 2007 21:14:44 -0000 X-Spam-Check-By: sourceware.org Received: from fk-out-0910.google.com (HELO fk-out-0910.google.com) (209.85.128.190) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 Oct 2007 21:14:39 +0000 Received: by fk-out-0910.google.com with SMTP id 26so1155372fkx for ; Sat, 13 Oct 2007 14:14:36 -0700 (PDT) Received: by 10.82.183.19 with SMTP id g19mr9110380buf.1192310076504; Sat, 13 Oct 2007 14:14:36 -0700 (PDT) Received: from ?78.130.34.112? ( [78.130.34.112]) by mx.google.com with ESMTPS id 5sm2963439nfv.2007.10.13.14.14.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Oct 2007 14:14:35 -0700 (PDT) Message-ID: <471134B9.5060609@portugalmail.pt> Date: Sat, 13 Oct 2007 23:20: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: gdb-patches@sourceware.org Subject: Re: [rfc] Teach i386 prologue reader about _alloca and __main References: <47112285.2080100@portugalmail.pt> <20071013202615.GA9946@caradoc.them.org> In-Reply-To: <20071013202615.GA9946@caradoc.them.org> 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/msg00365.txt.bz2 Daniel Jacobowitz wrote: > On Sat, Oct 13, 2007 at 08:54:45PM +0100, Pedro Alves wrote: >> * gdbarch.sh (gdbarch_skip___main_call): New. >> * gdbarch.h, gdbarch.c: Regenerate. > > I don't have time or experience to look at this thoroughly right now, > but I did notice this: you can just put this in i386's gdbarch_tdep. > The __main call is not i386 specific. Eg. arm-wince has the same problem. More precisely, it matches the targets where this is true in gcc/function.c. void expand_main_function (void) { #if (defined(INVOKE__main) \ || (!defined(HAS_INIT_SECTION) \ && !defined(INIT_SECTION_ASM_OP) \ && !defined(INIT_ARRAY_SECTION_ASM_OP))) emit_library_call (init_one_libfunc (NAME__MAIN), LCT_NORMAL, VOIDmode, 0); #endif } I've also experimented with calling skip__main_call from find_function_start_sal, but later moved it into i386-tdep.c. That's still an open issue for me. --- symtab.c 2007-10-13 20:08:38.000000000 +0100 +++ symtab.c.skip_main 2007-10-13 20:08:32.000000000 +0100 @@ -2493,6 +2493,16 @@ find_function_start_sal (struct symbol * /* Recalculate the line number (might not be N+1). */ sal = find_pc_sect_line (pc, SYMBOL_BFD_SECTION (sym), 0); } + + /* Skip __main call in targets without .init section and/or that + emit a call to __main in main as the first thing after the + prologue, before user code. */ + if (funfirstline + && gdbarch_skip___main_call_p (current_gdbarch) + && SYMBOL_LINKAGE_NAME (sym) + && strcmp (SYMBOL_LINKAGE_NAME (sym), "main") == 0) + pc = gdbarch_skip___main_call (current_gdbarch, pc); + sal.pc = pc; return sal; I'll experiment a bit more with it. I'm mostly asking for advice on: - Is the gdb-only solution preferable? That is, the line info currently marks the prologue ending *before* the __main call. Last year's version changed that, this one doesn't. Does anyone see any problem with that? Cheers, Pedro Alves