From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17278 invoked by alias); 13 Feb 2003 21:56:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17270 invoked from network); 13 Feb 2003 21:56:58 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 13 Feb 2003 21:56:58 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id QAA05612; Thu, 13 Feb 2003 16:45:50 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id QAA25922; Thu, 13 Feb 2003 16:56:56 -0500 Message-ID: <01dd01c2d3aa$d4c1b1c0$0202040a@catdog> From: "Kris Warkentin" To: "Mark Kettenis" Cc: "Andrew Cagney" , References: <1c3601c2cbc1$72eac3b0$0202040a@catdog> <3E40387D.50001@redhat.com> <008f01c2ce4b$427295f0$2a00a8c0@dash> <86lm0r3nha.fsf@elgar.kettenis.dyndns.org> Subject: Re: patch to add QNX NTO i386 support Date: Thu, 13 Feb 2003 21:56:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-02/txt/msg00310.txt.bz2 > > #define HANDLE_SVR4_EXEC_EMULATORS 1 > > #include "solib.h" /* shared lib support */ > > Including solib.h is fine. However I wonder why you need > HANDLE_SVR4_EXEC_EMULATORS. AFAIK this deals with Solaris BCP > (running SunOS 4 a.out files on Solaris 2 a.k.a. SunOS 5). What is > its relevance on QNX? Could this be the reason that you need to set > SOLIB_BKPT_NAME? I've discovered why HANDLE_SVR4_EXEC_EMULATORS is needed but I'm not sure of the correct way to fix it. The relevant code is from solib-svr4.c below. A typical remote qnx debugging session would be something like this: kewarken@CATDOG ~/test $ ntox86-gdb GNU gdb 5.2.1qnx-326 QNX Neutrino 6.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-cygwin --target=ntox86". (gdb) target qnx ren:10000 Remote debugging using ren:10000 (gdb) sym blah Reading symbols from blah...done. (gdb) upload blah /tmp/blah (gdb) r /tmp/blah Starting program: /tmp/blah (gdb) b main Breakpoint 1 at 0x8048402: file blah.c, line 10. (gdb) c Continuing. Breakpoint 1, main () at blah.c:10 10 func(); The problem that we're running into is that exec_bfd is NULL in the code below so we fall back on the 'hard way' which is not really necessary (if exec_bfd is set). On the native qnx gdb, this isn't a problem because exec_bfd is set when main() calls attach_command() which calls exec_file_attach(). What I'd like to know is at what point should I stuff exec_bfd? In the case of remote debugging, the file with the symbols is '/home/kewarken/test/blah' and the file being run (on the remote) is /tmp/blah. We need to set exec_bfd to point to the same file as the one we've read symbols from but the question is, when and where? cheers, Kris static CORE_ADDR locate_base (void) { if (debug_base == 0) { if (exec_bfd != NULL && bfd_get_flavour (exec_bfd) == bfd_target_elf_flavour) debug_base = elf_locate_base (); #ifdef HANDLE_SVR4_EXEC_EMULATORS /* Try it the hard way for emulated executables. */ else if (!ptid_equal (inferior_ptid, null_ptid) && target_has_execution) proc_iterate_over_mappings (look_for_base); #endif } return (debug_base); }