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

Pedro Alves
2013-06-25T15:01:26Z

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