mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-20 09:58:19 +08:00
678c7a56ce
In his review of my BZ 25631 patch series, Pedro was unable to reproduce the regression which should occur after patch #1, "Remove hack for GDB which sets the section size to 0", is applied. Pedro was using an ld version older than 2.30. Version 2.30 introduced the linker option -z separate-code. Here's what the man page has to say about it: Create separate code "PT_LOAD" segment header in the object. This specifies a memory segment that should contain only instructions and must be in wholly disjoint pages from any other data. In ld version 2.31, use of separate-code became the default for Linux/x86. So, really, 2.31 or later is required in order to see the regression that occurs in recent Linux distributions when only the bfd hack removal patch is applied. For the test case in question, use of the separate-code linker option means that the global variable "coremaker_ro" ends up in a separate load segment (though potentially with other read-only data). The upshot of this is that when only patch #1 is applied, GDB won't be able to correctly access coremaker_ro. The reason for this is due to the fact that this section will now have a non-zero size, but will not have contents from the core file to find this data. So GDB will ask BFD for the contents and BFD will respond with zeroes for anything from those sections. GDB should instead be looking in the executable for this data. Failing that, it can then ask BFD for a reasonable value. This is what a later patch in this series does. When using ld versions earlier than 2.31 (or 2.30 w/ the -z separate-code option explicitly provided to the linker), there is the possibility that coremaker_ro ends up being placed near other data which is recorded in the core file. That means that the correct value will end up in the core file, simply because it resides on a page that the kernel chooses to put in the core file. This is why Pedro wasn't able to reproduce the regression that should occur after fixing the BFD hack. This patch places a big chunk of memory, two pages worth on x86, in front of "coremaker_ro" to attempt to force it onto another page without requiring use of that new-fangled linker switch. Speaking of which, I considered changing the test to use -z separate-code, but this won't work because it didn't exist prior to version 2.30. The linker would probably complain of an unrecognized switch. Also, it likely won't be available in other linkers not based on current binutils. I.e. it probably won't work in FreeBSD, NetBSD, etc. To make this more concrete, this is what *should* happen when attempting to access coremaker_ro when only patch #1 is applied: Core was generated by `/mesquite2/sourceware-git/f28-coresegs/bld/gdb/testsuite/outputs/gdb.base/coref'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f68205deefb in raise () from /lib64/libc.so.6 (gdb) p coremaker_ro $1 = 0 Note that this result is wrong; 201 should have been printed instead. But that's the point of the rest of the patch series. However, without this commit, or when using an old Linux distro with a pre-2.31 ld, this is what you might see instead: Core was generated by `/mesquite2/sourceware-git/f28-coresegs/bld/gdb/testsuite/outputs/gdb.base/coref'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f63dd658efb in raise () from /lib64/libc.so.6 (gdb) p coremaker_ro $1 = 201 I.e. it prints the right answer, which sort of makes it seem like the rest of the series isn't required. Now, back to the patch itself... what should be the size of the memory chunk placed before coremaker_ro? It needs to be at least as big as the page size (PAGE_SIZE) from the kernel. For x86 and several other architectures this value is 4096. I used MAPSIZE which is defined to be 8192 in coremaker.c. So it's twice as big as what's currently needed for most Linux architectures. The constant PAGE_SIZE is available from <sys/user.h>, but this isn't portable either. In the end, it seemed simpler to just pick a value and hope that it's big enough. (Running a separate program which finds the page size via sysconf(_SC_PAGESIZE) and then passes it to the compilation via a -D switch seemed like overkill for a case which is rendered moot by recent linker versions.) Further information can be found here: https://sourceware.org/pipermail/gdb-patches/2020-May/168168.html https://sourceware.org/pipermail/gdb-patches/2020-May/168170.html Thanks to H.J. Lu for telling me about the '-z separate-code' linker switch. gdb/testsuite/ChangeLog: * gdb.base/coremaker.c (filler_ro): New global constant.
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.