From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21025 invoked by alias); 15 May 2013 11:05:59 -0000 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 Received: (qmail 21016 invoked by uid 89); 15 May 2013 11:05:59 -0000 X-Spam-SWARE-Status: No, score=-8.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 15 May 2013 11:05:58 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4FB5uCF031740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 May 2013 07:05:56 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r4FB5sta011786; Wed, 15 May 2013 07:05:55 -0400 Message-ID: <51936C12.90904@redhat.com> Date: Wed, 15 May 2013 11:05:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sourceware.org Subject: Re: [RFC/commit] ppc-aix core file relocation. References: <1368614045-16575-1-git-send-email-brobecker@adacore.com> In-Reply-To: <1368614045-16575-1-git-send-email-brobecker@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00513.txt.bz2 On 05/15/2013 11:34 AM, Joel Brobecker wrote: > This patch fixes the problem by extending corelow's core_xfer_partial > into handling the TARGET_OBJECT_LIBRARIES_AIX object. This requires > that we go through the gdbarch vector rather than just purely the > target_ops. This means that I needed the code decoding the loader > info to be in the aix-tdep module, which also forces me to extract > the data from that loader info by hand. We're lucky, the information > appears to be stable across platforms. Thanks! This is definitely the way to go. > + If CLOSE_LDINFO_FD is nonzero, then this routine also closes > + the ldinfo_fd file descriptor. This is useful when the ldinfo > + data is obtained via ptrace, as ptrace opens a file descriptor > + for each and every entry; but we cannot use this descriptor > + as the consumer of the XML library list might live in a different > + process. */ How interesting. So AIX's list is better than glibc in that we could use that descriptor to avoid the "library file gdb opens is no longer the same as the inferior opened" issue. > + > +LONGEST > +rs6000_aix_ld_info_to_xml (struct gdbarch *gdbarch, const gdb_byte *ldi_buf, > + gdb_byte *readbuf, ULONGEST offset, LONGEST len, > + int close_ldinfo_fd) > +/* A structured representation of one entry read from the ld_info > + binary data provided by the AIX loader. */ > + > +struct ld_info > +{ > + int next; I'm surprised this is signed. It was unsigned on Ulrich's version: http://sourceware.org/ml/gdb-patches/2007-05/msg00321.html Anyway, I skimmed it and it looked good to me. -- Pedro Alves