This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [MIPS] Check info->executable to create DT_MIPS_RLD_MAP


Maciej W. Rozycki wrote:
> Sent: Monday, June 24, 2013 7:56 AM
> To: Chao-Ying Fu
> Cc: 'David Daney'; 'Richard Sandiford'; binutils@sourceware.org
> Subject: RE: [MIPS] Check info->executable to create DT_MIPS_RLD_MAP
> 
> Chao-ying,
> 
>  I failed to cc the binutils list with my reply for some 
> reason, so here 
> it is again, with a further note.
> 
> On Sat, 22 Jun 2013, Maciej W. Rozycki wrote:
> 
> > On Sat, 22 Jun 2013, Chao-Ying Fu wrote:
> > 
> > > David Daney wrote:
> > > > >    When using "-pie", LD doesn't create the 
> DT_MIPS_RLD_MAP entry,
> > > > > because LD checks "!info->shared" and the "-pie" flag sets 
> > > > "info->shared" to true.
> > > > > Note that LD checks "info->executable" to create DT_DEBUG, and
> > > > > creating DT_MIPS_RLD_MAP should be similar to 
> creating DT_DEBUG.
> > > > > Ex:
> > > > >        /* SGI object has the equivalence of DT_DEBUG in the
> > > > >           DT_MIPS_RLD_MAP entry.  This must come 
> first because glibc
> > > > >           only fills in DT_MIPS_RLD_MAP (not DT_DEBUG) and 
> > > > some tools
> > > > >           may only look at the first one they see.  */
> > > > >        if (!info->shared
> > > > >            && !MIPS_ELF_ADD_DYNAMIC_ENTRY (info, 
> > > > DT_MIPS_RLD_MAP, 0))
> > > > >          return FALSE;
> > > > >
> > > > 
> > > > Probably you want info->executable here too.
> > > > 
> > > > I have tried simple programs with -pie and they seem to 
> work as is. 
> > > > What failures are you seeing?  Does the libgcc unwinder 
> use this?
> > 
> >  David, just as the comments say -- these tags are used by 
> debuggers and 
> > both GDB (in the native mode) and gdbserver make use of them.  The 
> > comments also explain why DT_DEBUG is not sufficient (on the 
> > MIPS/Linux/glibc target) and getting DT_MIPS_RLD_MAP right 
> is important.
> > 
> > >   I hit an issue in gdbserver that fails to return a 
> shared-library list,
> > > because gdbserver tries to find the DT_MIPS_RLD_MAP entry from
> > > a program that is built with -pie.
> > 
> >  Chao-ying, your consideration appears right to me, please 
> offer a patch.
> 
>  Please make sure ld.so handles it correctly first though as 
> I suspect it 
> may segfault.  The thing is in a PIE the segment containing the word 
> pointed to by DT_MIPS_RLD_MAP may get mapped to an arbitrary 
> memory area 
> and it does not immediately appear to me that ld.so relocates 
> the value of 
> the DT_MIPS_RLD_MAP tag by the base address, which it has to 
> if it wants 
> to use it (it may be enough to add l->l_addr to the value 
> retrieved in 
> ELF_MACHINE_DEBUG_SETUP).  But perhaps I'm missing something here.
> 

  From my testing on MIPS Debian 6, I got set fault on a program linked with my new LD.
Ex:
(gdb) info r
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 2aac2208 00010ac0 2aad8000 2aadbcb0 6474e552 6474e552 00000000
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   2aac6ed2 0000002f 2aacc3e8 2aac8ce0 00000000 6ffffe71 00000007 00000000
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  2aacc000 2aadb2b8 2aadaf00 2aadb2b8 2aadb7b8 00000000 2aac8000 00000000
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  00000000 2aabae60 2aadafe4 00000000 2aae3010 7fe60b00 7fe60b00 2aaab6fc
        status       lo       hi badvaddr    cause       pc
      0100a413 00000002 00000007 00010ac0 0080000c 2aaab81c
          fcsr      fir  restart
      00000000 01739300 00000000
(gdb) x/i 0x2aaab81c
0x2aaab81c:     sw      a0,0(v0)
(gdb) x/x 0x10ac0
0x10ac0 <__RLD_MAP>:    Cannot access memory at address 0x10ac0

  So, without modifying ld.so, we cannot use the new LD.  Right?
If yes, will we still want to change LD?

  By the way, my current LD patch is as follows.  One side effect of this patch
is that _DYNAMIC_LINK/_DYNAMIC_LINKING will be created with -pie linking.
Is _DYNAMIC_LINK/_DYNAMIC_LINKING needed for -pie as well?

Index: elfxx-mips.c
===================================================================
RCS file: /cvs/src/src/bfd/elfxx-mips.c,v
retrieving revision 1.354
diff -u -p -r1.354 elfxx-mips.c
--- elfxx-mips.c	22 May 2013 08:39:52 -0000	1.354
+++ elfxx-mips.c	21 Jun 2013 21:28:34 -0000
@@ -7111,7 +7111,7 @@ _bfd_mips_elf_add_symbol_hook (bfd *abfd
     }
 
   if (SGI_COMPAT (abfd)
-      && ! info->shared
+      && info->executable
       && info->output_bfd->xvec == abfd->xvec
       && strcmp (*namep, "__rld_obj_head") == 0)
     {
@@ -7219,7 +7219,7 @@ _bfd_mips_elf_create_dynamic_sections (b
   htab->sstubs = s;
 
   if (!mips_elf_hash_table (info)->use_rld_obj_head
-      && !info->shared
+      && info->executable
       && bfd_get_linker_section (abfd, ".rld_map") == NULL)
     {
       s = bfd_make_section_anyway_with_flags (abfd, ".rld_map",
@@ -7283,7 +7283,7 @@ _bfd_mips_elf_create_dynamic_sections (b
 	(void) bfd_set_section_alignment (abfd, s, MIPS_ELF_LOG_FILE_ALIGN (abfd));
     }
 
-  if (!info->shared)
+  if (info->executable)
     {
       const char *name;
 
@@ -9070,7 +9070,7 @@ _bfd_mips_elf_size_dynamic_sections (bfd
 	      info->combreloc = 0;
 	    }
 	}
-      else if (! info->shared
+      else if (info->executable
 	       && ! mips_elf_hash_table (info)->use_rld_obj_head
 	       && CONST_STRNEQ (name, ".rld_map"))
 	{
@@ -9129,7 +9129,7 @@ _bfd_mips_elf_size_dynamic_sections (bfd
 	 DT_MIPS_RLD_MAP entry.  This must come first because glibc
 	 only fills in DT_MIPS_RLD_MAP (not DT_DEBUG) and some tools
 	 may only look at the first one they see.  */
-      if (!info->shared
+      if (info->executable
 	  && !MIPS_ELF_ADD_DYNAMIC_ENTRY (info, DT_MIPS_RLD_MAP, 0))
 	return FALSE;
 
  Thanks a lot!

Regards,
Chao-ying


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]