This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [MIPS] Check info->executable to create DT_MIPS_RLD_MAP
- From: Chao-Ying Fu <Chao-Ying dot Fu at imgtec dot com>
- To: "'Maciej W. Rozycki'" <macro at codesourcery dot com>
- Cc: 'David Daney' <ddaney dot cavm at gmail dot com>, 'Richard Sandiford' <rdsandiford at googlemail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 24 Jun 2013 17:43:50 +0000
- Subject: RE: [MIPS] Check info->executable to create DT_MIPS_RLD_MAP
- References: <81D57523CB07B24881D63DE650C6ED82018D72B7 at BADAG02 dot ba dot imgtec dot org> <51C4ED0A dot 9010401 at gmail dot com> <81D57523CB07B24881D63DE650C6ED82018D7324 at BADAG02 dot ba dot imgtec dot org> <alpine dot LFD dot 2 dot 03 dot 1306220138240 dot 29828 at linux-mips dot org> <alpine dot DEB dot 1 dot 10 dot 1306241540190 dot 16287 at tp dot orcam dot me dot uk>
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