From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26728 invoked by alias); 23 Nov 2012 19:58:52 -0000 Received: (qmail 26719 invoked by uid 22791); 23 Nov 2012 19:58:52 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BJ X-Spam-Check-By: sourceware.org Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Nov 2012 19:58:47 +0000 Received: by mail-wg0-f43.google.com with SMTP id dq12so3326629wgb.12 for ; Fri, 23 Nov 2012 11:58:46 -0800 (PST) Received: by 10.180.88.138 with SMTP id bg10mr7886854wib.13.1353700726473; Fri, 23 Nov 2012 11:58:46 -0800 (PST) Received: from [192.168.0.105] ([2.82.184.91]) by mx.google.com with ESMTPS id t17sm10280700wiv.6.2012.11.23.11.58.45 (version=SSLv3 cipher=OTHER); Fri, 23 Nov 2012 11:58:45 -0800 (PST) Message-ID: <50AFD573.1090601@gmail.com> Date: Fri, 23 Nov 2012 19:58:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] use gdbarch_addr_bits_remove for entry point address References: <1353404184-22073-1-git-send-email-yao@codesourcery.com> In-Reply-To: <1353404184-22073-1-git-send-email-yao@codesourcery.com> Content-Type: text/plain; charset=ISO-2022-JP 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: 2012-11/txt/msg00632.txt.bz2 On 11/20/2012 09:36 AM, Yao Qi wrote: > This patch attempts to clear the lsb of the entry address, which might > be set by compiler for thumb code. > > This patch does something similar to this one, > > RFC: Handle ISA bits for the entry point > http://sourceware.org/ml/gdb-patches/2009-07/msg00682.html > > Regression tested on arm-none-linux-gnueabi. Is it OK? > > gdb: > > 2012-11-20 Daniel Jacobowitz > Kazu Hirata > Yao Qi > > * objfiles.c (init_entry_point_info): Use gdbarch_addr_bits_remove. > * solib-svr4.c (exec_entry_point): Likewise. > * symfile.c (generic_load): Call gdbarch_addr_bits_remove on > the entry address. > --- > gdb/objfiles.c | 5 +++++ > gdb/solib-svr4.c | 5 ++++- > gdb/symfile.c | 1 + > 3 files changed, 10 insertions(+), 1 deletions(-) > > diff --git a/gdb/objfiles.c b/gdb/objfiles.c > index a1db8c6..3374c68 100644 > --- a/gdb/objfiles.c > +++ b/gdb/objfiles.c > @@ -353,6 +353,11 @@ init_entry_point_info (struct objfile *objfile) > /* Examination of non-executable.o files. Short-circuit this stuff. */ > objfile->ei.entry_point_p = 0; > } > + > + if (objfile->ei.entry_point_p) > + objfile->ei.entry_point > + = gdbarch_addr_bits_remove (objfile->gdbarch, > + objfile->ei.entry_point); > } If this is needed here, then it would look to me that gdbarch_convert_from_func_ptr_addr would be needed too. See the function right below init_entry_point_info: /* If there is a valid and known entry point, function fills *ENTRY_P with it and returns non-zero; otherwise it returns zero. */ int entry_point_address_query (CORE_ADDR *entry_p) { struct gdbarch *gdbarch; CORE_ADDR entry_point; if (symfile_objfile == NULL || !symfile_objfile->ei.entry_point_p) return 0; gdbarch = get_objfile_arch (symfile_objfile); entry_point = symfile_objfile->ei.entry_point; /* Make certain that the address points at real code, and not a function descriptor. */ entry_point = gdbarch_convert_from_func_ptr_addr (gdbarch, entry_point, ¤t_target); /* Remove any ISA markers, so that this matches entries in the symbol table. */ entry_point = gdbarch_addr_bits_remove (gdbarch, entry_point); *entry_p = entry_point; return 1; } So you if put the gdbarch_addr_bits_remove call in init_entry_point_info, ISTM the same call in entry_point_address_query is no longer necessary. And that it'd be better to move gdbarch_convert_from_func_ptr_addr too, I'd think (and I don't know if there's an order they should be called in; moving both preserves the order). Maybe there are yet other callers that could have gdbarch_addr_bits_remove calls removed as redundant too, I haven't checked. -- Pedro Alves