On Tuesday 10 June 2014 11:48:15 Mark Wielaard wrote:
On Mon, 2014-06-09 at 21:05 +0200, Thilo Schulz wrote:
> When adding data to existing sections in ELF files, libelf may corrupt
> those sections, i.e. overwrite the existing data if certain conditions
> are met.
>
> If an Elf_Scn structure has seen a call to elf_rawdata(scn) before but no
> call to elf_getdata(scn), scn->read_data flag is set, but not
> scn->data_list_rear.
Do you happen to have a small testcase that shows the buggy behavior?
Sure. This is an excerpt from the final program. A short word on what it is
supposed to do in my practical application:
I am doing a project for the AVR platform, which is mixed C/assembly. For
command parser functions that are called out of assembly into C code, I need
to replace the final return statements with rjmps back to
program code in an object file generated from my assembly.
So I want to add new symbols and relocations to a cmd.o file.
Find as attachment a simple program, which checks for the presence of the two
symbols cmd_response and cmd_noresponse and adds them if they don't exist.
Since the AVR architecture is 8 bit, I am only using Elf32_ structures
throughout, so you may need to compile test .o objects with -m32 for the test
program to work on them.
I was wondering whether we want to check scn->rawdata.s directly,
or if
we could rely on ELF_F_FILEDATA being set for scn->flags?
Seems reasonable though I don't know the code as well as you do I guess.
As a further note: A similar bug, albeit for slightly different reasons, occurs
when adding relocations. Adding a relocation with elf_newdata() then
elf_update()
results in the old data being "forgotten" if there was no elf_getdata() call
before to load that data into memory. The cause is a bit different because in
this case, there was not a call to elf_rawdata() before and this still
happened. I imagine, this might also be a problem for string tables.
--
Best regards,
Thilo Schulz