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]

[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


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