mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-25 04:49:54 +08:00
6e22494e50
GDB tries to skip prologue for .S files according to .debug_line but it then
places the breakpoint to a location where it is never hit.
This is because #defines in .S files cause prologue skipping which is
completely inappropriate, for s390x:
glibc/sysdeps/unix/syscall-template.S
78:/* This is a "normal" system call stub: if there is an error,
79: it returns -1 and sets errno. */
80:
81:T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
82: ret
00000000000f4210 T __select
Line Number Statements:
Extended opcode 2: set Address to 0xf41c8
Advance Line by 80 to 81
Copy
Advance PC by 102 to 0xf422e
Special opcode 6: advance Address by 0 to 0xf422e and Line by 1 to 82
Special opcode 34: advance Address by 2 to 0xf4230 and Line by 1 to 83
Advance PC by 38 to 0xf4256
Extended opcode 1: End of Sequence
Compilation Unit @ offset 0x28b3e0:
<0><28b3eb>: Abbrev Number: 1 (DW_TAG_compile_unit)
<28b3ec> DW_AT_stmt_list : 0x7b439
<28b3f0> DW_AT_low_pc : 0xf41c8
<28b3f8> DW_AT_high_pc : 0xf4256
<28b400> DW_AT_name : ../sysdeps/unix/syscall-template.S
<28b423> DW_AT_comp_dir : /usr/src/debug////////glibc-2.17-c758a686/misc
<28b452> DW_AT_producer : GNU AS 2.23.52.0.1
<28b465> DW_AT_language : 32769 (MIPS assembler)
without debuginfo or with debuginfo and the fix - correct address:
(gdb) b select
Breakpoint 1 at 0xf4210
It is also where .dynsym+.symtab point to:
00000000000f4210 T __select
00000000000f4210 W select
with debuginfo, without the fix:
(gdb) b select
Breakpoint 1 at 0xf41c8: file ../sysdeps/unix/syscall-template.S, line 81.
One part is to behave for asm files similar way like for 'locations_valid':
/* Symtab has been compiled with both optimizations and debug info so that
GDB may stop skipping prologues as variables locations are valid already
at function entry points. */
unsigned int locations_valid : 1;
The other part is to extend the 'locations_valid'-like functionality more.
Both minsym_found and find_function_start_sal need to be patched, otherwise
their addresses do not match and GDB regresses on ppc64:
gdb/ChangeLog
2015-06-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* linespec.c (minsym_found): Reset sal.PC for COMPUNIT_LOCATIONS_VALID
and language_asm..
* symtab.c (find_function_start_sal): Likewise.
gdb/testsuite/ChangeLog
2015-06-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/amd64-prologue-skip.S: New file.
* gdb.arch/amd64-prologue-skip.exp: New file.
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.