PATCH: Add updelfhdr

Tristan Gingold gingold@adacore.com
Mon Jan 4 14:46:00 GMT 2010


On Jan 4, 2010, at 3:39 PM, H.J. Lu wrote:

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

I only partially agree.  if objdump doesn't display everything readelf dumps that's because it is not
implemented.

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

Well, that's a point or a bug ;-)

Tristan.



More information about the Binutils mailing list