This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
[RFA:] Fix PR14481 for almost all a.out-targets
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: binutils at sourceware dot org
- Date: Wed, 7 Nov 2012 06:12:20 +0100
- Subject: [RFA:] Fix PR14481 for almost all a.out-targets
I got wary of seeing my autotester reporting bfdtest1 as failing
ever since it was added. It fails forcris-linux-gnu and
cris-elf as they mistakenly both have targ_defvec=cris_aout_vec.
Anyway, the patch is as simple as below. Probably the same for
other "failing" object formats.
I tested the patch on targets for most bfd aout-target-vectors
where there was at least one targ_defvec mentioning them in
config.bfd.
I did not test b_out_vec_little_host, as i960-aout is not
recognized by GAS configury (nor any other i960-target it
seems).
I did not test host_aout_vec which just seems like a weirdo
"#if 0"ed target that should be deleted. (Maybe native only? I
couldn't find where HAVE_host_aout_vec is #defined.)
I did not test vaxnetbsd_vec; GAS and BFD can't agree on a
commonly recognized tuple also recognized by config.sub. Nope,
neither of vax-aout, vax-netbsdaout, vax-netbsd-aout fit.
I did test this for crosses from i686-linux to:
armeb-aout (aout_arm_big_vec)
armel-aout (aout_arm_little_vec)
tic30-unknown-aout (tic30_aout_vec)
cris-aout (cris_aout_vec)
cris-elf (also cris_aout_vec, see above)
i386-freebsdaout (i386freebsd_vec)
i386-netbsdaout (i386netbsd_vec)
i386-linux-aout (i386linux_vec)
i386-aout (i386aout_vec)
m68k-aout (aout0_big_vec)
m68k-linuxaout (m68klinux_vec)
m68k-netbsdaout (m68knetbsd_vec)
ns32k-pc532-mach (pc532machaout_vec)
pdp11-dec-aout (pdp11_aout_vec)
sparc64-aout (sunos_big_vec)
sparc-linuxaout (sparclinux_vec)
sparc-netbsdaout (sparcnetbsd_vec)
Ok, pdp11-dec-aout may not really count; assembly for several
test-cases (specifically critical parts for the bfdtest1 tests)
fail with an assertion. There may be similarly losing targets.
Where the FAIL for a bfdtest1-related test was present as such,
this patch fixes for most of the targets. There are no
regressions for "make check" anywhere.
There are two exceptions, i.e. targets not fixed:
tic30-unknown-aout (on inspection it needs a separate similar
patch as it has its own MY_close_and_cleanup due to copypaste -
let that be a warning to all copypaste-happy people) and
sparc-unknown-linux-gnuaout (for unknown reasons, but the patch
fixes two out of three related FAILs), down from:
FAIL: ar long file names (bfdtest1)
FAIL: ar thin archive (bfdtest1)
FAIL: ar thin archive with nested archive (bfdtest1)
to
Running /home/hp/binutils/src/binutils/testsuite/binutils-all/ar.exp ...
FAIL: ar thin archive with nested archive (bfdtest1)
Moreover and hopefully more interesting, I ran "make
check-binutils" in a setup where all compiled tools (gas, ar,
bfdtest1, objcopy etc.) are running under valgrind for the
test-suite run. (I'm hesitant to submit that as a patch; lots of
patches to the testsuite library and a need to, in your
test-harness, set environment variables for each tool so it
should probably be implemented some other way.)
Anyway, this setup showed no hidden badness for the fixed
bfdtest1-related test-cases; they didn't FAIL in this setup.
For sparc-unknown-linux-gnuaout, there's a lot *less*
valgrind-output for the remaining FAIL, with the remaining
output being the same, AFAICT. See also further below.
The patch follows the style of the other "small routines" in
aout-target.h. The function has to be in that file and not in
aoutx.h as it has to refer to MY_bfd_free_cached_info, which is
not available in aoutx.h. The function head-comment is
admittedly lame and "add one to x":ish, but it didn't seem
appropriate to do without any head-comment.
Ok to commit?
bfd:
* aout-target.h (MY_close_and_cleanup): Make
Index: bfd/aout-target.h
===================================================================
RCS file: /cvs/src/src/bfd/aout-target.h,v
retrieving revision 1.43
diff -p -u -r1.43 aout-target.h
--- bfd/aout-target.h 11 Jul 2011 15:03:03 -0000 1.43
+++ bfd/aout-target.h 6 Nov 2012 23:37:40 -0000
@@ -577,7 +577,18 @@ MY_bfd_final_link (bfd *abfd, struct bfd
#endif
#ifndef MY_close_and_cleanup
-#define MY_close_and_cleanup MY_bfd_free_cached_info
+
+/* Handle closing of a BFD inclusing the resource-releasing parts. */
+
+static bfd_boolean
+MY_close_and_cleanup (bfd *abfd)
+{
+ if (!MY_bfd_free_cached_info (abfd))
+ return FALSE;
+
+ return _bfd_generic_close_and_cleanup (abfd);
+}
+
#endif
#ifndef MY_get_dynamic_symtab_upper_bound
There were some incidental discoveries; while running
check-binutils I *did* notice some failing tests, unrelated to
the patch, in the valgrind-setup:
Running /home/hp/binutils/src/binutils/testsuite/binutils-all/compress.exp ...
FAIL: objcopy (objcopy compress debug sections)
FAIL: objcopy (objcopy compress debug sections in archive)
FAIL: objdump compress debug sections
These seem to be due to uninitialized-bugs in the host
zlib-1.2.3.18.fc9 (!) or less likely, in valgrind-3.3.0-3. I
won't waste time on them. Just mentioned for comparison in case
someone will try a similar setup on a newer host.
There's also exposed what seems to be some *actual* binutils bugs:
Running /home/hp/binutils/src/binutils/testsuite/binutils-all/objcopy.exp ...
Version /home/hp/binutils/obj/l/binutils/objcopy 2.23.51.20121106
FAIL: objcopy -i --interleave-width
Running /home/hp/binutils/src/binutils/testsuite/binutils-all/objdump.exp ...
Version /home/hp/binutils/obj/l/binutils/objdump 2.23.51.20121106
FAIL: objdump -W
FAIL: objdump -WL
In binutils.log, for "FAIL: objcopy -i --interleave-width":
==6873== Invalid read of size 1
==6873== at 0x804C958: copy_section (objcopy.c:2826)
==6873== by 0x8077D3B: bfd_map_over_sections (section.c:1329)
==6873== by 0x804B042: copy_object (objcopy.c:1935)
==6873== by 0x804C31A: copy_file (objcopy.c:2346)
==6873== by 0x804E1C1: main (objcopy.c:4051)
==6873== Address 0x402d011 is 0 bytes after a block of size 9 alloc'd
==6873== at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==6873== by 0x8076146: bfd_malloc (libbfd.c:183)
==6873== by 0x808659F: bfd_get_full_section_contents (compress.c:181)
==6873== by 0x804C847: copy_section (objcopy.c:2783)
==6873== by 0x8077D3B: bfd_map_over_sections (section.c:1329)
==6873== by 0x804B042: copy_object (objcopy.c:1935)
==6873== by 0x804C31A: copy_file (objcopy.c:2346)
==6873== by 0x804E1C1: main (objcopy.c:4051)
(repeated once)
and for the other two it's something like:
==7197== Source and destination overlap in memcpy(0x40366C0, 0x40366C0, 89)
==7197== at 0x40076D9: memcpy (mc_replace_strmem.c:402)
==7197== by 0x8088E9C: bfd_get_section_contents (section.c:1549)
==7197== by 0x8097734: bfd_get_full_section_contents (compress.c:185)
==7197== by 0x80D7742: bfd_generic_get_relocated_section_contents (reloc.c:6809)
==7197== by 0x80973E1: bfd_simple_get_relocated_section_contents (simple.c:239)
==7197== by 0x804F8C6: load_specific_debug_section (objdump.c:2278)
==7197== by 0x804F9DA: dump_dwarf_section (objdump.c:2361)
==7197== by 0x808909B: bfd_map_over_sections (section.c:1329)
==7197== by 0x804DAEF: dump_dwarf (objdump.c:2411)
==7197== by 0x804E14B: dump_bfd (objdump.c:3242)
==7197== by 0x804ECD6: display_any_bfd (objdump.c:3329)
==7197== by 0x804ED85: display_file (objdump.c:3404)
Those are pretty recent IIRC, at least from this year.
brgds, H-P