This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #16046] Static dlopen correction fallout fixes
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>, Allan McRae <allan at archlinux dot org>
- Cc: Ondřej Bílka <neleai at seznam dot cz>, <libc-alpha at sourceware dot org>
- Date: Thu, 30 Jan 2014 07:43:42 +0000
- Subject: Re: [PATCH][BZ #16046] Static dlopen correction fallout fixes
- Authentication-results: sourceware.org; auth=none
- References: <20131017174710 dot GA4993 at domone dot podge> <20131025210328 dot 39E69746B6 at topped-with-meat dot com> <alpine dot DEB dot 1 dot 10 dot 1310252347350 dot 12843 at tp dot orcam dot me dot uk> <20140116203847 dot GB20838 at domone dot podge> <alpine dot DEB dot 1 dot 10 dot 1401172303320 dot 4268 at tp dot orcam dot me dot uk> <20140117233957 dot 64E307441B at topped-with-meat dot com> <alpine dot DEB dot 1 dot 10 dot 1401271320170 dot 4268 at tp dot orcam dot me dot uk> <alpine dot DEB dot 1 dot 10 dot 1401291054290 dot 4268 at tp dot orcam dot me dot uk> <20140129184954 dot 1BFFA74441 at topped-with-meat dot com>
On Wed, 29 Jan 2014, Roland McGrath wrote:
> The changes look fine to me. Allan has the say on whether they are safe
> enough for 2.19, but I think that the fact that only static binaries should
> be affected should lower the bar here. That case would be helped if you
> could verify that your patch results in no code changes to ld.so or libc.so
> (i.e. compare objdump -rd on old vs new).
The binaries are not exactly the same:
$ ls -gG ld-2.18.90.so.*
-rwxr-xr-x 1 779616 Jan 30 06:40 ld-2.18.90.so.new
-rwxr-xr-x 1 779624 Jan 30 06:28 ld-2.18.90.so.old
$ mips-linux-gnu-objdump -rd ld-2.18.90.so.old > ld-2.18.90.dump.old
$ mips-linux-gnu-objdump -rd ld-2.18.90.so.new > ld-2.18.90.dump.new
$ diff -u ld-2.18.90.dump.old ld-2.18.90.dump.new
--- ld-2.18.90.dump.old 2014-01-30 07:03:31.561961606 +0000
+++ ld-2.18.90.dump.new 2014-01-30 07:03:22.561961867 +0000
@@ -1,5 +1,5 @@
-ld-2.18.90.so.old: file format elf32-tradbigmips
+ld-2.18.90.so.new: file format elf32-tradbigmips
Disassembly of section .text:
@@ -23823,7 +23823,7 @@
17a04: 8f9980c8 lw t9,-32568(gp)
17a08: 24840ca8 addiu a0,a0,3240
17a0c: 24a50b60 addiu a1,a1,2912
- 17a10: 24060287 li a2,647
+ 17a10: 24060286 li a2,646
17a14: 0320f809 jalr t9
17a18: 24e70d7c addiu a3,a3,3452
17a1c: 8f998068 lw t9,-32664(gp)
@@ -24153,7 +24153,7 @@
17f24: 8f9980c8 lw t9,-32568(gp)
17f28: 24840d50 addiu a0,a0,3408
17f2c: 24a50b60 addiu a1,a1,2912
- 17f30: 24060302 li a2,770
+ 17f30: 240602fa li a2,762
17f34: 0320f809 jalr t9
17f38: 24e70da0 addiu a3,a3,3488
17f3c: 00000000 nop
$
-- that's not very informative, so let's try harder:
$ mips-linux-gnu-objdump -rS ld-2.18.90.so.old > ld-2.18.90.sdump.old
$ mips-linux-gnu-objdump -rS ld-2.18.90.so.new > ld-2.18.90.sdump.new
$ diff -u ld-2.18.90.sdump.old ld-2.18.90.sdump.new
--- ld-2.18.90.sdump.old 2014-01-30 07:12:52.651649151 +0000
+++ ld-2.18.90.sdump.new 2014-01-30 07:12:59.151635166 +0000
@@ -1,5 +1,5 @@
-ld-2.18.90.so.old: file format elf32-tradbigmips
+ld-2.18.90.so.new: file format elf32-tradbigmips
Disassembly of section .text:
[...]
@@ -54211,19 +54212,19 @@
179ec: 2406015d li a2,349
179f0: 0320f809 jalr t9
179f4: 24e70d7c addiu a3,a3,3452
+ /* Finally, unlink the data structure and free it. */
if (imap->l_prev != NULL)
imap->l_prev->l_next = imap->l_next;
else
{
assert (nsid != LM_ID_BASE);
- ns->_ns_loaded = imap->l_next;
179f8: 8f848050 lw a0,-32688(gp)
179fc: 8f858050 lw a1,-32688(gp)
17a00: 8f878050 lw a3,-32688(gp)
17a04: 8f9980c8 lw t9,-32568(gp)
17a08: 24840ca8 addiu a0,a0,3240
17a0c: 24a50b60 addiu a1,a1,2912
- 17a10: 24060287 li a2,647
+ 17a10: 24060286 li a2,646
17a14: 0320f809 jalr t9
17a18: 24e70d7c addiu a3,a3,3452
#ifdef SHARED
[...]
@@ -54942,19 +54967,19 @@
17f0c: 24e70d64 addiu a3,a3,3428
17f10: 1000ffdf b 17e90 <_dl_close+0x3c>
17f14: 8fbc0010 lw gp,16(sp)
- }
-
- if (__builtin_expect (map->l_direct_opencount, 1) == 0)
- GLRO(dl_signal_error) (0, map->l_name, NULL, N_("shared object not open"));
+ struct link_map *map = _map;
- /* Acquire the lock. */
+ /* First see whether we can remove the object at all. */
+ if (__builtin_expect (map->l_flags_1 & DF_1_NODELETE, 0))
+ {
+ assert (map->l_init_called);
17f18: 8f848050 lw a0,-32688(gp)
17f1c: 8f858050 lw a1,-32688(gp)
17f20: 8f878050 lw a3,-32688(gp)
17f24: 8f9980c8 lw t9,-32568(gp)
17f28: 24840d50 addiu a0,a0,3408
17f2c: 24a50b60 addiu a1,a1,2912
- 17f30: 24060302 li a2,770
+ 17f30: 240602fa li a2,762
17f34: 0320f809 jalr t9
17f38: 24e70da0 addiu a3,a3,3488
17f3c: 00000000 nop
$
[I've stripped noise from different source and binary code interleaving
chosen by `objdump' where the binary code hasn't changed]
-- ah, so these are changes to the second argument (passed in the a2
register, loaded with an immediate value here) to __assert_fail calls
expanded from assert triggers in elf/dl-close.c (`jalr t9' is the MIPS PIC
call instruction, the t9 register holds the address of the callee). This
argument is the value of the __LINE__ special macro and given that the
patch removes some lines from the file, no doubt this must have changed.
This is further reflected in section headers that also explain the
difference in the file size:
$ mips-linux-gnu-objdump -h ld-2.18.90.so.old > ld-2.18.90.sect.old
$ mips-linux-gnu-objdump -h ld-2.18.90.so.new > ld-2.18.90.sect.new
$ diff -u ld-2.18.90.sect.old ld-2.18.90.sect.new
--- ld-2.18.90.sect.old 2014-01-30 07:25:13.771961592 +0000
+++ ld-2.18.90.sect.new 2014-01-30 07:25:18.771961749 +0000
@@ -1,5 +1,5 @@
-ld-2.18.90.so.old: file format elf32-tradbigmips
+ld-2.18.90.so.new: file format elf32-tradbigmips
Sections:
Idx Name Size VMA LMA File off Algn
@@ -49,17 +49,17 @@
CONTENTS, READONLY, DEBUGGING
22 .debug_abbrev 000090c7 00000000 00000000 00077090 2**0
CONTENTS, READONLY, DEBUGGING
- 23 .debug_line 0000d0ce 00000000 00000000 00080157 2**0
+ 23 .debug_line 0000d0c7 00000000 00000000 00080157 2**0
CONTENTS, READONLY, DEBUGGING
- 24 .debug_frame 000020b0 00000000 00000000 0008d228 2**2
+ 24 .debug_frame 000020b0 00000000 00000000 0008d220 2**2
CONTENTS, READONLY, DEBUGGING
- 25 .debug_str 000055b6 00000000 00000000 0008f2d8 2**0
+ 25 .debug_str 000055b6 00000000 00000000 0008f2d0 2**0
CONTENTS, READONLY, DEBUGGING
- 26 .debug_loc 000205b1 00000000 00000000 0009488e 2**0
+ 26 .debug_loc 000205b1 00000000 00000000 00094886 2**0
CONTENTS, READONLY, DEBUGGING
- 27 .debug_ranges 00004d28 00000000 00000000 000b4e3f 2**0
+ 27 .debug_ranges 00004d28 00000000 00000000 000b4e37 2**0
CONTENTS, READONLY, DEBUGGING
- 28 .gnu.attributes 00000010 00000000 00000000 000b9b67 2**0
+ 28 .gnu.attributes 00000010 00000000 00000000 000b9b5f 2**0
CONTENTS, READONLY
- 29 .mdebug.abi32 00000000 00000000 00000000 000b9b77 2**0
+ 29 .mdebug.abi32 00000000 00000000 00000000 000b9b6f 2**0
CONTENTS, READONLY
$
-- so the size of debug line information has decreased and consequently
the file offset of all the following sections moved backwards.
Given the insignificance of these changes for ld.so's operation I hope
that they are acceptable even for 2.19.
> I'm not sure off hand how best to construct a good test case.
> But I think that we should not call the subject closed until
> we have an effective regression test in the suite.
I agree.
Maciej