From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5337 invoked by alias); 1 May 2007 23:07:49 -0000 Received: (qmail 5325 invoked by uid 22791); 1 May 2007 23:07:49 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 May 2007 00:07:46 +0100 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l41N7i0i059308 for ; Tue, 1 May 2007 23:07:44 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l41N7icN4030576 for ; Wed, 2 May 2007 01:07:44 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l41N7hOM010992 for ; Wed, 2 May 2007 01:07:44 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l41N7h4n010988; Wed, 2 May 2007 01:07:43 +0200 Message-Id: <200705012307.l41N7h4n010988@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 2 May 2007 01:07:43 +0200 Subject: Re: [rfc] Remove mips/tm-linux.h To: drow@false.org (Daniel Jacobowitz) Date: Tue, 01 May 2007 23:07:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20070501202710.GA23630@caradoc.them.org> from "Daniel Jacobowitz" at May 01, 2007 04:27:10 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-05/txt/msg00019.txt.bz2 Daniel Jacobowitz wrote: > While working on mips64-linux more today, I decided to remove its > DEPRECATED_TM_FILE setting. The problem was that it overrode > IN_SOLIB_DYNSYM_RESOLVE_CODE, which isn't a gdbarch method; it lives > in the solib_ops instead. That had been on my list ;-) Thanks for beating me to it. I'd been thinking of a somewhat different approach: the svr4 implementation checks really for two different things: - whether the pc is inside the dynamic loader - whether the pc is in a call stub on its way to the dynamic loader The first is clearly a "solib" property, but the second is arguably more of a gdbarch/osabi property. So I'd thought on removing the in_plt_section check from svr4_in_solib_dynsym_resolve_code, make a new gdbarch method with a default implementation to check both in_solib_dynsym_resolve_code and in_plt_section, and use that new method in infrun.c instead of in_solib_dynsym_resolve_code. Then mips gdbarch could override that method, and call the standard in_solib_dynsym_resolve_code plus its own special check for dynamic stubs. But I don't really object to your solution either, in particular: > +/* Set the solib operations for GDBARCH to NEW_OPS. */ > + > +extern void set_solib_ops (struct gdbarch *gdbarch, > + struct target_so_ops *new_ops); something like this is certainly a good idea. (E.g. to clean up the mess NTO currenly has w.r.t. solib overrides ...) Either way, there goes the last definition of IN_SOLIB_DYNSYM_RESOLVE_CODE, so infrun.c could be cleaned up a bit as a follow-on. > Tested on mips64-linux, all three ABIs, no change in results. I'm wondering why you didn't run into this #error in gdbarch.h: #if !defined (GDB_TM_FILE) && defined (CANNOT_FETCH_REGISTER) #error "Non multi-arch definition of CANNOT_FETCH_REGISTER" #endif #if !defined (GDB_TM_FILE) && defined (CANNOT_STORE_REGISTER) #error "Non multi-arch definition of CANNOT_STORE_REGISTER" #endif because the mips-linux NM file still defines those two macros, and you just removed the TM file ... I did run into the that problem on ia64. That's the reason why I was recently trying to remove the mips-linux NM file, before going after the TM -- but that still isn't quite resolved. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com