This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PATCH: Add updelfhdr
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Tristan Gingold <gingold at adacore dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, binutils at sourceware dot org
- Date: Mon, 4 Jan 2010 06:39:19 -0800
- Subject: Re: PATCH: Add updelfhdr
- References: <20091217184650.GA29177@lucon.org> <4B3CB946.7000904@redhat.com> <6dc9ffc80912310716x2945434aie199099aa3b033cc@mail.gmail.com> <178F5C14-8F50-4E8C-A641-55989017F3C9@adacore.com>
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.