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: [RFA:] Fix PR14481 for almost all a.out-targets


On Tue, Nov 6, 2012 at 9:12 PM, Hans-Peter Nilsson
<hans-peter.nilsson@axis.com> wrote:
> 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

Truncated ChangeLog entry?

> 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.
>

I will take a look.

Thanks.

-- 
H.J.


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