From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17833 invoked by alias); 12 Oct 2010 20:12:09 -0000 Received: (qmail 17818 invoked by uid 22791); 12 Oct 2010 20:12:06 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Oct 2010 20:11:51 +0000 Received: (qmail 1384 invoked from network); 12 Oct 2010 20:11:49 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Oct 2010 20:11:49 -0000 Date: Tue, 12 Oct 2010 20:12:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: matthew.gretton-dann@arm.com, rearnsha@arm.com, gdb-patches@sourceware.org Subject: Re: [rfa] ARM prologue parsing support for Thumb-2 instructions Message-ID: <20101012201145.GZ8337@caradoc.them.org> References: <20101008132747.GO23776@caradoc.them.org> <201010121656.o9CGuMDo025020@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010121656.o9CGuMDo025020@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-10/txt/msg00203.txt.bz2 On Tue, Oct 12, 2010 at 06:56:22PM +0200, Ulrich Weigand wrote: > Hmm, I noticed one set of problems is due to the __libc_do_syscall > function you added in this patch: > > http://sourceware.org/ml/gdb-patches/2010-10/msg00137.html Wrong link :-) > The GDB prologue parser would actually be easily capable of understanding > this function prologue. However, it doesn't work because GDB does not even > find the start of the function in the first place, since the symbol is > present only in the regular symbol table (which is stripped), and not in > the dynamic symbol table, because of the ".hidden" directive. > > Is there any particular reason why this function could not be at least > .protected instead? It doesn't need to be exposed; that would waste space in the dynamic symbol table. Plus I don't understand the complete details, but .protected is problematic. I am not real sympathetic. Either have unwind info, or if you have a system where that is not practical, implement .ARM.exidx based unwinding for GDB. It can't be done in general but it can be done for the standard table formats; there's code in readelf to dump them, for instance. -- Daniel Jacobowitz CodeSourcery