RFA: broken strip/objcopy

[H.J. Lu]

On Fri, Apr 24, 2009 at 4:16 PM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> 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 am not happy the whole PE/COFF in BFD.

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

Sorry, I don't have time for this.

-- 
H.J.