This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #16 from Stefan Markovic <stefan.markovic@rt-rk.com> ---
(In reply to Jozef Lawrynowicz from comment #15)
> Created attachment 11237 [details]
> gdb-write.patch
> 
> Further investigation into what can actually be modified when a BFD is
> opened for update, revealed that the fix for this is quite simple.
> 
> When a BFD is opened for update (i.e. with "r+" flags, or indirectly via
> "gdb --write"), abfd->output_has_begun is set to TRUE, which heavily
> restricts
> what you can do to the BFD.
> 
> - New sections cannot be created
> - The size of sections cannot be modified
> 
> This means the ELF header, program headers and sections headers will not
> change, so they do not need to be written in _bfd_elf_write_object_contents,
> as the original versions already exist in the BFD.
> 
> Even though the patch modifies write_object_contents to exit before section
> contents are written to the output BFD, any changes to contents made using
> bfd_set_section_contents or by setting memory in gdb --write have already
> been
> written, so are present in the executable after closing the BFD.
> 
> The patch is attached as gdb-write.patch.
> 
> I tested it on current binutils-gdb master for x86_64-pc-linux-gnu and
> msp430-elf in a couple of ways.
> - Build the attached "modify-bfd.c", and run it with an ELF file as an
>   argument, check the string FOOBAR appears in the .comment section.
> - Run "gdb --write -batch -ex "set {int}main = 0x1234" FILE", then check the
>   contents of memory at main are 0x1234
> - Run "gdb --write -ex q FILE", verify the before and after versions of FILE
>   are identical.
> 
> I used the set of resulting executable and object files left over from the
> linker testsuite as input.

This makes sense and it works.

I have also tested this patch for x86_64 on master binutils-gdb and for
nanomips-elf (without any other of Your previous patches applied) and I can
confirm that this one entirely solves this issue. Even with relocatable object
files regardless whether that is supposed to work or not.

Thank You for Your time and help.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]