[Bug gdb/20948] --write option to GDB causes segmentation fault

["jozef.l at mittosystems dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20948

--- Comment #14 from Jozef Lawrynowicz <jozef.l at mittosystems dot com> ---
Ok, I reproduced the "invalid string offset" errors.

Empty sections cause problems when re-opening a linked executable as their file
offset is not usually the same as what it would be if they had size > 0. In my
case, multiple empty, but not SHT_NOBITS, sections shared the same file offset
after linking.
This results in the section to segment mapping changing after an invocation of
--write.

The reason this causes these errors is because the most of the actual contents
of the file have not been updated to reflect changes in the metadata. For
example, if the segment map changes so that there is an additional segment,
then the file offsets of all the sections will increase as there is extra data
in the program header. But the contents of the executable file have not been
moved to reflect the changed offsets, which results in the symbol/string table
looking a mess.

So we need to "slurp" the contents of the BFD when it is first opened, and then
write it back at the end.

Then there is the question of whether the executable file should should be
allowed to change after it is opened for update, but no explicit modifications
are made. The BFD library code uses the section headers to rebuild the metadata
such as the segment mapping. Perhaps when opening an executable for update it
should use the program headers to ensure that the layout of the executable does
not change.

After opening an executable for update, then closing it without making any
changes, I would have expected the ELF data in the before and after executables
to be identical, but maybe this is not how it's supposed to work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.