Pedro Alves 169692ce6c Fix "gdb --write" with core files
If you load a core file into GDB with the --write option, or "set
write on" (equivalent), and then poke memory expecting it to patch the
core binary, you'll notice something odd -- the write seems to
succeed, but in reality, it doesn't.  The value you wrote doesn't
persist.  Like so:

 $ gdb -q --write -c testsuite/outputs/gdb.base/patch/gcore.test
 [New LWP 615986]
 Core was generated by `/home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/patch/patch'.
 Program terminated with signal SIGTRAP, Trace/breakpoint trap.
 #0  0x0000555555555131 in ?? ()
 (gdb) p *(unsigned char *)0x0000555555555131 = 1
 $1 = 1 '\001'
 (gdb) p *(unsigned char *)0x0000555555555131
 $2 = 185 '\271'
 (gdb)

Diffing hexdumps of before/after patching, reveals that a "0x1" was
actually written somewhere in the file.  The problem is that the "0x1"
was written at the wrong offset in the file...

That happens because _bfd_elf_set_section_contents does this to seek
to the section's offset:

  pos = hdr->sh_offset + offset;
  if (bfd_seek (abfd, pos, SEEK_SET) != 0
      || bfd_bwrite (location, count, abfd) != count)
    return false;

... and 'hdr->sh_offset' is zero, so we seek to just OFFSET, which is
incorrect.  The reason 'hdr->sh_offset' is zero is that
kernel-generated core files normally don't even have a section header
table (gdb-generated ones do, but that's more an accident than a
feature), and indeed elf_core_file_p doesn't even try to read sections
at all:

  /*  Core files are simply standard ELF formatted files that partition
      the file using the execution view of the file (program header table)
      rather than the linking view.  In fact, there is no section header
      table in a core file.

      The process status information (including the contents of the general
      register set) and the floating point register set are stored in a
      segment of type PT_NOTE.  We handcraft a couple of extra bfd sections
      that allow standard bfd access to the general registers (.reg) and the
      floating point registers (.reg2).  */

  bfd_cleanup
  elf_core_file_p (bfd *abfd)

Changing _bfd_elf_set_section_contents from:

  pos = hdr->sh_offset + offset;

to:

  pos = section->filepos + offset;

fixes it.  If we do that however, the tail end of
_bfd_elf_set_section_contents ends up as a copy of
_bfd_generic_set_section_contents, so just call the latter, thus
eliminating some duplicate code.

New GDB testcase included, which exercises both patching an executable
and patching a core file.  Patching an executable already works
without this fix, because in that case BFD reads in the sections
table.  Still, we had no testcase for that yet.  In fact, we have no
"set write on" testcases at all, this is the first one.

Tested on x86-64 GNU/Linux, gdb, ld, binutils, and gas.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18227
Change-Id: I0f49f58b48aabab2e269f2959b8fd8a7fe36fdce
2022-05-13 10:56:05 +01:00
2022-05-13 10:56:05 +01:00
2022-01-22 12:08:55 +00:00
2020-09-25 10:24:44 -04:00
2022-05-11 09:49:20 +09:30
2022-01-22 12:08:55 +00:00
2022-05-13 10:56:05 +01:00
2022-05-10 08:15:40 -06:00
2022-05-02 10:54:19 -04:00
2022-05-10 11:21:37 +09:30
2022-05-13 16:43:15 +09:30
2021-11-15 12:20:12 +10:30
2022-05-13 16:43:15 +09:30
2022-05-13 14:32:54 +09:30
2022-01-28 08:25:42 -05:00
2022-03-11 08:58:31 +00:00
2022-03-11 08:58:31 +00:00

		   README for GNU development tools

This directory contains various GNU compilers, assemblers, linkers, 
debuggers, etc., plus their support routines, definitions, and documentation.

If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README;  if with a libg++ release,
see libg++/README, etc.  That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.

It is now possible to automatically configure and build a variety of
tools with one command.  To build all of the tools contained herein,
run the ``configure'' script here, e.g.:

	./configure 
	make

To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
	make install

(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''.  You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)

If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make.  For example (assuming sh/bash/ksh):

	CC=gcc ./configure
	make

A similar example using csh:

	setenv CC gcc
	./configure
	make

Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc.  See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.

REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
on where and how to report problems.
Description
Unofficial mirror of sourceware binutils-gdb repository. Updated daily.
Readme 780 MiB
Languages
C 51.8%
Makefile 22.4%
Assembly 12.3%
C++ 6%
Roff 1.4%
Other 5.4%