Re: relocation of shared libs not based at 0

[Kevin Buettner <kevinb@redhat.com>]

On Jan 5, 12:39pm, Paul Koning wrote:

> So the real answer is simple: the LM_ADDR entries have to be adjusted
> by the as-linked start VMA of the library.  The only problem I ran
> into is that I couldn't find a clean way to obtain that value in gdb.
> I did come up with something that worked; if there are better ways to
> do this I would be interested.
> 
> My fix is in a modified 5.3, but the relevant source is unchanged from
> 5.3 to 6.0.  So attached is a diff for 6.0 that shows the fix I
> described.  
> 
> 	    paul
> 
> --- gdb/solib-svr4.c.orig	Fri Jun 13 17:56:27 2003
> +++ gdb/solib-svr4.c	Mon Jan  5 12:29:49 2004
> @@ -1375,8 +1375,29 @@
>  svr4_relocate_section_addresses (struct so_list *so,
>                                   struct section_table *sec)
>  {
> -  sec->addr    = svr4_truncate_ptr (sec->addr    + LM_ADDR (so));
> -  sec->endaddr = svr4_truncate_ptr (sec->endaddr + LM_ADDR (so));
> +  CORE_ADDR reloc;
> +  
> +  /* On NetBSD/MIPS at least, the library is mapped in two pieces.
> +     The section headers describe this: each shows the unrelocated
> +     virtual address of the section.  To figure out the relocated
> +     address, we have to adjust these by the base VMA of the library.
> +     
> +     There isn't a really clean way to figure out the offset of each
> +     section.  "filepos" doesn't do it, because that is the 
> +     file-relative offset, not the VMA offset.
> +
> +     So what we do is this: 
> +     Pick up the VMA (given by the header) of the first section,
> +     and subtract from that its filepos.  That's the unrelocated VMA
> +     of the library.  Subtract that from the unrelocated VMA
> +     of each section to get its relocation bias; add that to the
> +     library load address to get the relocated address.
> +  */
> +  reloc = so->sections->the_bfd_section->vma -
> +          so->sections->the_bfd_section->filepos;
> +
> +  sec->endaddr = svr4_truncate_ptr (sec->endaddr - reloc + LM_ADDR (so));
> +  sec->addr    = svr4_truncate_ptr (sec->addr - reloc + LM_ADDR (so));
>  }

I think something along these lines will be okay.  It may even be okay
as is.  I need to study the relationship between "vma" and "filepos"
to convince myself that it's okay.

I'll be very busy with other matters for the next couple of weeks.  Would
you mind pinging me in a few weeks?

In the interim, I'd like to find out what the QNX folks think of this
patch.  As I recall, QNX behaved in a similar fashion to NetBSD and
I'm wondering if Paul's patch would address those problems as well.

Kevin