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

[Pedro Alves <palves at redhat dot com>]

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?

-- 
Pedro Alves