From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27822 invoked by alias); 8 Mar 2007 17:54:34 -0000 Received: (qmail 27813 invoked by uid 22791); 8 Mar 2007 17:54:33 -0000 X-Spam-Check-By: sourceware.org Received: from mail.automotion.info (HELO brsmtp01.br-automation.com) (213.33.116.60) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Mar 2007 17:54:24 +0000 In-Reply-To: <20070308160501.GA8042@caradoc.them.org> To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Antwort: Re: relocations when doing file command at gdb prompt MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Roland Puntaier Date: Thu, 08 Mar 2007 17:54:00 -0000 Content-Type: text/plain; charset="US-ASCII" X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00140.txt.bz2 > Actually, ET_DYN is not quite either. It's more like a linked program > for the purpose of my question. Yes. Actually only the .plt .text and .data section find their way to the target device. > So, it's relocated already, but the relocations are still present. > No wonder GDB is doubling them. > ... > I don't see how we can sensibly distinguish the two cases. What > toolchain produced this file? GCC, but with -Wl,-q,-shared,-T,"YYY.x", i.e shared and with modified linker script, and the relocation info is kept because of a post-processing using it. This means there is no way to avoid the doubling and still keep the .rel sections without changing GDB code, doesn't it? Interesting that even (gdb)add-symbol-file NewProgram.out 0 -s data 0 (gdb)info line 29 yields a wrong address. In objfiles.c/objfile_relocate/(line 552) l->item[i].pc based on 0 would be very fine, because ANOFFSET (objfile->section_offsets, i) (line 529) turns out to be 0. Strange that these two don't fit together.