Re: RFA: broken strip/objcopy

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

H.J. Lu wrote:
> On Fri, Apr 24, 2009 at 2:58 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> To change PE parameters, we should call bfd_copy_private_bfd_data
>> before changing PE parameters. This patch works for me on
>> both w32 and w64.

>>        * objcopy.c (copy_object): Call bfd_copy_private_bfd_data
>>        before changing PE parameters.

> We can't calll bfd_copy_private_bfd_data first. This patch only
> copies pe_opthdr.

> Index: bfd/peXXigen.c
> 
> +  /* pe_opthdr is copied in copy_object.  */

  I'm still unhappy with the architecture of the whole thing.  It is bad
enough for binutils to reach into bfd and twiddle its private bits, now bfd is
predicating its behaviour on the usage patterns of one specific client,
binutils.  However, I see that it's not without precedent, as ld/ also does this.

  I can confirm that this solves the FAILs, anyway.

  HJ, I think it would be very nice if you reworked your original patch to
provide a clean interface that gives access to pe_opthdr to clients of libbfd
through a coff backend vector.  Then binutils can do what it likes with a
local copy of the opthdr, but the copy private data function can still copy
it, which will DTRT when the client of libbfd is /not/ modifying the opthdr,
no?  As a quid-pro-quo, if you do this for pe_opthdr, I'll follow up with a
patch that does likewise for 'dll' and 'real_flags', which are the only other
two members accessed outside bfd, and then we can remove all the internal bfd
headers that get #include'd and it'll be nice and tidy.  How about it?

    cheers,
      DaveK