Instead of elf_memory() having to guess, which seems like it will confuse future users (esp if its behavior is not documented), can we make a new extended API routine elf_memory_mode() that takes in the mode, and clearly document that the old legacy one assumes readonly (or read-write if you change it)?
On Thu, Aug 29, 2024 at 9:48 AM Mark Wielaard <m...@klomp.org> wrote: > Hi, > > So we changed elf_memory so it pretends the in-memory Elf image is > read with ELF_C_READ_MMAP. This helps when calling elf_memory on > read-only memory which still wants to change some things about the Elf > like uncompress some sections (which changes the section header). > > With ELF_C_READ_MMAP libelf will make a copy of the section headers, > so any changes aren't written to the memory image (because that would > crash if the underlying memory is read-only). > > But that breaks another use case where elf_memory is used on rw memory > and then the section headers are updated using libelf and it is > expected those in-memory section headers reflect the changes. > > The problem of course is the elf_memory function doesn't take a "mode" > argument. So we have to guess. And make one or the other usage > unusable. > > I think we should assume the memory is read/write and at least header > updates are written back to the memory image. But that when only just > reading the image then nothing is changed and written back to the > image. > > This does mean that when explicitly uncompressing sections you have to > make sure the image is writable (because that updates the shdrs). > > Is that bad/unreasonable? > > Derek, would it make your use case impossible? > > John, what kind of Shdr changes are you expecting to get written back > to the memory image. Are there any issues that cannot be worked around > by always using the Shdr copy given back from (g)elf[32|64]_shdr? > > The patch I am thinking of is attached. > > Cheers, > > Mark
