PATCH: Add updelfhdr
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 <firstname.lastname@example.org> wrote:
>> On Dec 31, 2009, at 4:16 PM, H.J. Lu wrote:
>>> On Thu, Dec 31, 2009 at 6:46 AM, Nick Clifton <email@example.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
>>> 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 ;-)
More information about the Binutils