First of all I think you are posting to the wrong mailling list...
Second, for your problem: If this .note.MD5 (for example) section does
not need to be presented to the runtime loader or used during runtime,
you don't need to roll your own tool and you can just use objcopy(1)
to handle it:
1. Calculate the checksum or other stuff of the ELF, construct the Elf Notes
and then write all the bits to a temporary file, say '/tmp/foo'.
2. Execute objcopy to add a .note.MD5 section to the ELF file:
objcopy --add-section '.note.MD5=/tmp/foo' your_executable
(objcopy will handle all the string table, section table headers stuff etc)
On Tue, Feb 23, 2010 at 03:51:48PM +0100, Jay Vaughan wrote:
> Hi all,
> I am building an application which utilizes elfutils to add NOTE records to ELF files ..
> the purpose of this application is to provide a form of 'internal inventory control' over
> executables being used internally in our environment, and for that purpose a NOTE record
> is added to ELF files containing an MD5 sum of various parts of the ELF files themselves.
> All has been working fine with this utility program so far, but I have run into some
> problems with the handling of the string table - namely, where I was once realloc()'ing
> the string table data buffer and appending my new ".note.MD5" string to the list, and this
> isn't a very safe way of doing things - segfaults galore. Its not stable, alas, which is
> why I ended up implementing things this way only to discover on larger string tables that
> there was a problem, then tracing it back (valgrind to the rescue) to the fact that libelf
> doesn't like it when you realloc() its jiggly bits^W^Wstruct fields ..
> So my next approach has been to, as I'm iterating through the original ELF file, make a
> new string table out of the headers for each section, and upon completion (calculation of
> the to-be-inserted md5 string, construction of a proper NOTE record, attachment of the
> NOTE to the ELF file, etc.) I then burn the old string table and attach the new one.
> However, I'm really not sure if this is the safe way to do things, or if there is any
> other way that I could utilize - its a bit 'dodgy' to me at first blush, because what if
> there are cases out there in our ELF collection where I somehow mess up the string table,
> or what about the unspoken cases where a string table is expected to be something that
> libebl doesn't reproduce - I've already noted that some string tables created through
> libebl don't exactly 100% match the original ones (such as the ones in my redhat machines
> libc) due to internal optimization of the string table itself (finding overlaps and not
> inserting duplicate string values and so on..)
> My question to the wise developers on this list is whether or not there is another way to
> safely add an entry to an existing string table without doing too much
> create-new/destroy-old processing? I've added the use of libebl to my project, and I'm
> under way with completing my implementation as described above, but I'd really like some
> dialog with other ELF hackers on what they think about this method?
> BTW, I plan to release my "ELFNoter" app as GPL when its working/debugged .. I wonder if
> there is interest in including a working app to attach ELF Notes in the elfutils package?
> I'd be happy were that the case, to provide this app for review.
> Jay Vaughan
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> Elftoolchain-developers mailing list