From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4680 invoked by alias); 19 Jun 2007 22:43:54 -0000 Received: (qmail 4672 invoked by uid 22791); 19 Jun 2007 22:43:54 -0000 X-Spam-Check-By: sourceware.org Received: from elrond.portugalmail.pt (HELO elrond.portugalmail.pt) (195.245.179.181) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Jun 2007 22:43:52 +0000 Received: from localhost (localhost [127.0.0.1]) by elrond.portugalmail.pt (Postfix) with ESMTP id 08C9253315; Tue, 19 Jun 2007 23:43:49 +0100 (WEST) Received: from elrond.portugalmail.pt ([127.0.0.1]) by localhost (elrond.portugalmail.pt [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT17ERqhL5kF; Tue, 19 Jun 2007 23:43:48 +0100 (WEST) Received: from [127.0.0.1] (88.210.68.130.rev.optimus.pt [88.210.68.130]) (Authenticated sender: pedro_alves@portugalmail.pt) by elrond.portugalmail.pt (Postfix) with ESMTP id C717353319; Tue, 19 Jun 2007 23:43:45 +0100 (WEST) Message-ID: <46785C09.8070500@portugalmail.pt> Date: Tue, 19 Jun 2007 22:43:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org CC: Ulrich Weigand Subject: Re: For example only, updated Windows DLL support and gdbserver DLL support References: <20070619191938.GA26206@caradoc.them.org> <200706192000.l5JK0ZVU014446@d12av02.megacenter.de.ibm.com> <20070619201223.GA29049@caradoc.them.org> In-Reply-To: <20070619201223.GA29049@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000750-2, 19-06-2007), Outbound message X-Antivirus-Status: Clean 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: 2007-06/txt/msg00381.txt.bz2 Daniel Jacobowitz wrote: > Ulrich Weigand wrote: >>> I'm not sure how much trouble you'll have reporting the correct >>> relocations for an object file. Do you get something based on >>> sections, or do AIX object files have a fixed number of segments? >> XCOFF seems to be a bit limited in that respect, I understand there >> is just "Text" and "Data". The AIX ldinfo structure provides: > > Perfect. Then GDB's xcoff reader can report that the object file has > two "segments", one text and one data. > Are .text and .data really loaded as one segment like on windows, or can AIX load them separately at arbitrary addresses irrespective of the order that they have on the file? The bfd view of the order of the sections may be different from what the target would report. One might need to take that into account. Eg: On file: sect1, .text 0x000001000 (seg0) sect2, .data 0x000100000 (seg1) On load: .text 0x010000000 (seg0) .data 0x001100000 (seg1) report .text as seg0 and .data as seg1, relocate 0x000001000 to 0x010000000 relocate 0x000100000 to 0x001100000 OK. --- Eg2: On file: sect1, .data 0x000002000 (seg0) sect2, .text 0x000200000 (seg1) On load: .text 0x020000000 (seg0) .data 0x002200000 (seg1) report .text as seg0 and .data as seg1, (bad) relocate 0x000002000 to 0x020000000 (bad) relocate 0x000200000 to 0x002200000 (bad) NOK. Cheers, Pedro Alves