From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10461 invoked by alias); 10 Jun 2003 18:38:47 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10445 invoked from network); 10 Jun 2003 18:38:46 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 10 Jun 2003 18:38:46 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h5AIckH06366 for ; Tue, 10 Jun 2003 14:38:46 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5AIckI05125; Tue, 10 Jun 2003 14:38:46 -0400 Received: from localhost.localdomain (vpn50-31.rdu.redhat.com [172.16.50.31]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5AIciE09086; Tue, 10 Jun 2003 14:38:44 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h5AIcdu22092; Tue, 10 Jun 2003 11:38:39 -0700 Date: Tue, 10 Jun 2003 18:38:00 -0000 From: Kevin Buettner Message-Id: <1030610183839.ZM22091@localhost.localdomain> In-Reply-To: "Raja Saleru" "GAB side - how to resolve unresolved symbols" (Jun 3, 7:41pm) References: To: "Raja Saleru" , Subject: Re: GAB side - how to resolve unresolved symbols MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00169.txt.bz2 On Jun 3, 7:41pm, Raja Saleru wrote: > I am porting GDB Server on Vendor OS ( micro itron) on sh target. > The Target already has OS and TCP/IP and others. > In host side Linux environment, I have application. These applications uses > OS and TCP/IP service calls. > After compiling the application, I will downloading to target and the > linking takes place at target side. > I am going to reboot the target. In the host side, gdb has symbols, but the > addresses are not fixed. > After linking the application at target side, the linked version contains > the debug info as well as complete image, which is going to run on target. > The image has been created in elf / Dwarf 2 format. > > The linking at target takes places at any time dynamically. Whenever linking > happens, the target reboots. > For debugging the application, in host side all the symbols should be > resolved. I don't want to copy the whole liked version of image into host > side. > > 1. How can I re-solve the un-resolved symbols at host side by sending only > required > addresses of un-resolved symbols at host ? It seems to me that you might be able to use the shared library machinery to do what you want. > 2. if we assume that at target side, we have some utility, after linking > this utility will generates a table > which contains the symbols and their addresses. then how can I update at > host side ? I believe some facilities have been recently added to gdb for handling split executables / symbol tables. You might want to take a look... > 3. I found out some commands in gdb > symbol file - use symbol table from file > load file - dynamically link file and add its symbols > add-sym file addr - read additional symbols from file, dynamically > located at address addr > > from these commands can I solve my problem ? > what format the above commands expects the file ? The only command that *might* be appropriate for your purposes is "add-symbol-file". But that assumes that you know the addresses at which the various sections have been relocated to on the target. My guess is that even if it works, it'll prove to be too cumbersome for real debugging. I think you should investigate the following two approaches: 1) Use the shared library machinery in gdb to get gdb to do the relocations for you. It's likely that you'll need to write a target specific solib backend (on the gdb side) to do this. There will also be some target side work needed. or 2) After relocation (linking) on the target, send a symbol file back to the host for gdb to load. My guess is that (2) would be quicker to implement, but that (1) would be easier for the user. Kevin