CRiSP Blog

libelf brokenness

I do dislike libelf - its just an important library for manipulating
executables, but when it goes wrong, you are SOL trying to determine
what *it* did wrong, rather than your application.

As I diagnose the backwards compatibility issues on later binutils,
I found that we have a new section .gnu_hash which exists instead
of .hash. Older dynamic linkers dont like these executables.

You can tell gcc/ld to write old style formats, but this is a nuisance
to go through every makefile, adding the switch and potentially
autodetecting if the platform you are on or are building for supports this
switch.

Much easier to simple patch the ELF executable.

But a simple piece of code like the following creates a broken ELF
file, and looking at the libelf source doesnt easily lend itself
to determining why.

I am currently looking to write my own libelf library, to make it
easier to do what *I* want.


if (elf_version(EV_CURRENT) == EV_NONE) {
printf("%s: not an ELF file\n", fname);
return -1;
}
if ((fd = open64(fname, O_RDWR)) < 0) {
if (debug)
printf("Ignoring %s\n", fname);
return 0;
}
if ((elf = elf_begin(fd, ELF_C_RDWR, NULL)) == NULL) {
printf("%s: elf_begin failed - %s\n", fname, elf_errmsg(elf_errno()));
return -1;
}

// Following line, which does *nothing* causes the
// emitted updated file to be a corrupt ELF. Why? Who
// knows. That would require a lot of code reading in
// elf_update() to figure out what is happening.
elf64_getehdr(elf);

elf_update(elf, ELF_C_WRITE);


Post created by CRiSP v10.0.2c-b5917


Read more http://crtags.blogspot.com/2010/11/libelf-brokenness.html

Testimonials

"After looking for a good text editor for UNIX for several years I finally found one that met my needs in CRiSP. I have used vi, emacs, xcoral (not to mention edt, teco, brief, tpu, etc, etc.) but prefer using CRiSP for two main (but not exclusive) reasons. First is the language sensitive syntax colorization and second for it's ease of use (brief editor like functionality)."

paypal_horiz