Tidy bfdio to consistenly use containing archive

[H.J. Lu]

On Wed, Jun 13, 2018 at 5:10 AM, Maciej W. Rozycki <macro@mips.com> wrote:
> Hi Alan,
>
>> It's possible to have a valid "where" field for archives by always
>> using and updating the containing archive BFD.  That's what this patch
>> does.  Note that cache.c used to find the containing archive BFD
>> anyway for the iostream, so we're not really doing extra work, just
>> transferring it up to the correct abstraction level.
>>
>> The patch also gets rid of some hacks.  bfd_tell was called when
>> bfd_seek failed, in an attempt to correct "where".  That's got to be
>> papering over another problem, so that code has been removed.
>> bfd_read also had an "optimiziation" to return early when the number
>> of bytes was zero, and bfd_seek optimized calls that didn't move the
>> file pointer.  This was covering for a coff_slurp_line_table bug where
>> IO was attempted on a pe-dll BFD without an iovec.
>
>  It might be either the removal of what you call 'an "optimization"' or
> something else with your change, but in any case it has caused a serious
> performance regression seen in the GAS test suite with one of the MIPS
> test cases.  Execution times and the load before and after commit
> 5c4ce239a3ab are respectively:
>
> $ /usr/bin/time ../as-new   -o dump.o .../gas/testsuite/gas/mips/align.s
> 0.16user 0.31system 0:05.19elapsed 9%CPU (0avgtext+0avgdata 23904maxresident)k
> 0inputs+0outputs (0major+1590minor)pagefaults 0swaps
>
> and:
>
> $ /usr/bin/time ../as-new   -o dump.o .../gas/testsuite/gas/mips/align.s
> 2.48user 20.18system 0:33.97elapsed 66%CPU (0avgtext+0avgdata 23904maxresident)k
> 0inputs+0outputs (0major+1590minor)pagefaults 0swaps
>
> This causes intermittent test suite failures with MIPS targets:
>
> mips64-img-linux  +FAIL: MIPS align maximum
> mips64-kfreebsd-gnu  +FAIL: MIPS align maximum
> mips64-linux  +FAIL: MIPS align maximum
> mips64-mti-linux  +FAIL: MIPS align maximum
> mips64el-freebsd  +FAIL: MIPS align maximum
> mips64el-kfreebsd-gnu  +FAIL: MIPS align maximum
> mips64el-linux  +FAIL: MIPS align maximum
> mips64el-openbsd  +FAIL: MIPS align maximum
> mips64el-ps2-elf  +FAIL: MIPS align maximum
> mips64vr-elf  +FAIL: MIPS align maximum
>
> due to timeouts, which the regressed execution time in my test environment
> (where multiple test suites are run in parallel) is clearly on the verge
> of, e.g.:
>
> ../as-new   -o dump.o .../gas/testsuite/gas/mips/align.s
> Executing on host: sh -c {../as-new   -o dump.o .../gas/testsuite/gas/mips/align.s 2>&1}  /dev/null gas.out (timeout = 300)
> WARNING: program timed out.
>
> .../gas/testsuite/../../binutils/nm-new  -n dump.o
> Executing on host: sh -c {.../gas/testsuite/../../binutils/nm-new  -n dump.o >dump.out 2>gas.stderr}  /dev/null  (timeout = 300)
> .../gas/testsuite/../../binutils/nm-new: dump.o: file format not recognized
> FAIL: MIPS align maximum
>
>  Can you please have a look into it?
>
>   Maciej

Also see:

https://sourceware.org/bugzilla/show_bug.cgi?id=23282

-- 
H.J.