CRiSP Screenshots

paypal_horiz

CRiSP Newsletter

Join the CRiSP mailing list
CRiSP Newsletter


Receive HTML?

Testimonials

libelf brokenness PDF Print E-mail
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