Re: [PATCH, gdbserver] Further cleanup of FDPIC/DSBT divergences

[Luis Machado <lgustavo@codesourcery.com>]

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