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: PATCH: Add updelfhdr


On Mon, Jan 4, 2010 at 6:27 AM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Dec 31, 2009, at 4:16 PM, H.J. Lu wrote:
>
>> On Thu, Dec 31, 2009 at 6:46 AM, Nick Clifton <nickc@redhat.com> wrote:
>>> Hi H.J.
>>>
>>>> I wrote a program to update ELF header. ?Currently it can change
>>>> ELF machine type between L1OM and X86-64.
>>>
>>> I have to ask why make a separate program when you have just as easily added
>>> this functionality to objcopy ?
>>>
>>
>> For the same reason that we have both readelf and objdump?
>
> Readelf was initially written to double check BFD handling of ELF files, not for performance reasons.
> (at least according to the comments in readelf.c)

objdump can't do everything readelf does and readelf doesn't support
disassembler. They are complimentary.

>> objcopy is overkill.
>> It reads input into internal memory and write them out. My program updates files
>> in place. It doesn't read in the whole file into memory.
>
> It this performance critical ?
> I think it is dubious to have ELF specific tools in binutils. ?Readelf being the exception, binutils tools
> are expected to work on any file formats.
>

Well, we do have 2 ELF specific programs in binutils: readelf and gold.

I only want to update ELF header, nothing else.  objcopy basically will
rewrite the whole ELF file. Sometimes it fails, especially when the input isn't
generated by the GNU linker. updelfhdr doesn't have such a problem.

-- 
H.J.


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