From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1497 invoked by alias); 25 Jun 2013 15:03:35 -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 1484 invoked by uid 89); 25 Jun 2013 15:03:34 -0000 X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 25 Jun 2013 15:03:33 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1UrUmJ-0004R5-83 from Luis_Gustavo@mentor.com ; Tue, 25 Jun 2013 08:03:31 -0700 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by svr-orw-fem-01.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jun 2013 08:03:31 -0700 Received: from [172.30.13.6] ([172.30.13.6]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Jun 2013 08:03:29 -0700 Message-ID: <51C9B13F.3050500@codesourcery.com> Date: Tue, 25 Jun 2013 15:04:00 -0000 From: Luis Machado Reply-To: lgustavo@codesourcery.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pedro Alves CC: "'gdb-patches@sourceware.org'" , Mike Frysinger , Yao Qi Subject: Re: [PATCH, gdbserver] Further cleanup of FDPIC/DSBT divergences References: <51C34F14.8070803@codesourcery.com> <51C9B0BA.20707@redhat.com> In-Reply-To: <51C9B0BA.20707@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00707.txt.bz2 On 06/25/2013 12:01 PM, Pedro Alves wrote: > On 06/20/2013 07:51 PM, Luis Machado wrote: >> Hi, >> >> At some point, c6x used different data structures for its DSBT-based >> loadmap. >> >> DSBT-based >> >> struct target_loadmap >> { >> /* Protocol version number, must be zero. */ >> Elf32_Word version; >> /* Pointer to the DSBT table, its size, and the DSBT index. */ >> unsigned *dsbt_table; >> unsigned dsbt_size, dsbt_index; >> /* Number of segments in this map. */ >> Elf32_Word nsegs; >> /* The actual memory map. */ >> struct target_loadseg segs[/*nsegs*/]; >> }; >> >> FDPIC-based >> >> struct target_loadmap >> { >> /* Protocol version number, must be zero. */ >> Elf32_Half version; >> /* Number of segments in this map. */ >> Elf32_Half nsegs; >> /* The actual memory map. */ >> struct target_loadseg segs[/*nsegs*/]; >> }; >> >> We shared a little bit of code with FDPIC-based targets though... >> >> struct target_loadseg >> { >> /* Core address to which the segment is mapped. */ >> Elf32_Addr addr; >> /* VMA recorded in the program header. */ >> Elf32_Addr p_vaddr; >> /* Size of this segment in memory. */ >> Elf32_Word p_memsz; >> }; >> >> Things have changed, and c6x is now using the exact same data structures >> as FDPIC-based targets in uClibc. Please refer to >> http://lists.uclibc.org/pipermail/uclibc/2013-May/047789.html for the >> uClibc changes that led to this. >> >> Mark Salter, the author of the uClibc change, has agreed with the >> solution i proposed: >> http://lists.uclibc.org/pipermail/uclibc/2013-May/047790.html. >> >> It is all good, but we've been conditionalizing the c6x-specific >> target_loadmap data structure based on the presence of PT_GETDSBT. This >> has always been defined in uClibc and, since Mark's change, it doesn't >> work as a hint of whether to use the new or the old target_loadmap data >> structure anymore. Therefore we will/already have a potential problem >> with backwards compatibility. >> >> Bernhard has stated that backwards compatibility on uClibc's side is not >> a problem: http://lists.uclibc.org/pipermail/uclibc/2013-June/047801.html. >> >> With all that exposed, my proposed change to gdbserver is to drop all >> the DSBT-specific bits, remove their definitions and explicitly use >> FDPIC definitions instead, making things a little bit cleaner. >> >> In the following patch i also changed the code slightly to stop defining >> linux_read_loadmap to NULL and i switched to explicitly setting the >> target hook to NULL in the absence of the required definition. > > This is fine with me. > > Does this mean that solib-frv.c / solib-dsbt.c and the > solib-fdpic.c from > http://www.sourceware.org/ml/gdb-patches/2010-12/msg00291.html > > ? > > can all be combined? I'm confused on the current state > of bfin solib debugging -- it is still depending on out of > tree patches? > I wouldn't discard the possibility, but i still need to check if those are fully compatible with each other. Would be great to merge all those into a single file. Luis