Re: RFA: broken strip/objcopy

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.