The last uses of the F77_FOR_TARGET via passing f77 to GDB's compile
procedure were removed in this commit
commit 0ecee54cfd
Author: Tom Tromey <tromey@redhat.com>
Date: Wed Jun 29 17:50:47 2011 +0000
over 10 years ago. The last .f files in the testsuite by now are all
being compiled by passing 'f90' to the GDB compile, thus only actually
using F90_FOR_TARGET (array-element.f, block-data.f, subarray.f).
Gfortran in this case is backwards compatible with most f77 code as
claimed on gcc.gnu.org/fortran.
The reason we'd like to get rid of this now is, that we'll be
implementing a Fortran compiler identification mechanism, similar to the
C/Cpp existing ones. It would be using the Fortran preprocessor macro
defines to identify the Fortran compiler version at hand. We found it
inconsequent to only implement this for f90 but, on the other hand, f77
seems deprecated. So, with this commit we remove the remaining lines for
its support.
In the name matching unit tests in gdb/dwarf2/read.c, explain better
why we test symbols with \377 / 0xff characters (Latin1 'ÿ').
Change-Id: I517f13adfff2e4d3cd783fec1d744e2b26e18b8e
SYMBOL_REFERENCES_LOCAL can return true for undefined symbols. This
can result in a segfault when running sparc64 ld/testsuite/ld-vsb
tests that expect a failure.
* elfxx-sparc.c (_bfd_sparc_elf_finish_dynamic_symbol): Don't
access u.def.section on non-default visibility undefined symbol.
v850_elf_set_note is declared using an unsigned int note param in
elf32-v850.h but defined with enum c850_notes note in elf32-v850.c.
Current mainline gcc is warning about this. Huh.
* elf32-v850.c (v850_elf_set_note): Make "note" param an
unsigned int.
git commit 202be274a4 also missed adjusting a few testsuite files.
This fixes
i686-vxworks +FAIL: VxWorks shared library test 1
i686-vxworks +FAIL: VxWorks executable test 1 (dynamic)
git commit 202be274a4 went a little wild in removing trailing spaces
in gas/testsuite/gas/i386/{secidx.d,secrel.d}, causing
x86_64-w64-mingw32 +FAIL: i386 secrel reloc
x86_64-w64-mingw32 +FAIL: i386 secidx reloc
I could have just replaced the trailing space, but let's fix the
objdump output instead. Touches lots of testsuite files.
Patch
202be274a4 ("opcodes/i386: remove trailing whitespace from insns with zero operands")
causes this regression:
FAIL: gdb.trace/signal.exp: find syscall insn in kill
It's because the test still expects to match a whitespace after the
instruction, which the patch mentioned above removed. Remove the
whitespaces for the regexp.
Change-Id: Ie194273cc942bfd91332d4035f6eec55b7d3a428
The current "Specify Location" section of the GDB manual starts with:
"Several @value{GDBN} commands accept arguments that specify a location
of your program's code."
And then, such commands are documented as taking a "location"
argument. For example, here's a representative subset:
@item break @var{location}
@item clear @var{location}
@item until @var{location}
@item list @var{location}
@item edit @var{location}
@itemx info line @var{location}
@item info macros @var{location}
@item trace @var{location}
@item info scope @var{location}
@item maint agent @r{[}-at @var{location}@r{,}@r{]} @var{expression}
The issue here is that "location" isn't really correct for most of
these commands. Instead, the "location" argument is really a
placeholder that represent an umbrella term for all of the
"linespecs", "explicit location", and "address location" input
formats. GDB parses these and then finds the actual code locations
(plural) in the program that match. For example, a "location"
specified like "-function func" will actually match all the code
locations in the program that correspond to the address/file/lineno of
all the functions named "func" in all the loaded programs and shared
libraries of all the inferiors. A location specified like "-function
func -label lab" matches all the addresses of C labels named "lab" in
all functions named "func". Etc.
This means that several of the commands that claim they accept a
"location", actually end up working with multiple locations, and the
manual doesn't explain that all that well. In some cases, the command
will work with all the resolved locations. In other cases, the
command aborts with an error if the location specification resolves to
multiple locations in the program. In other cases, GDB just
arbitrarily and silently picks whatever is the first resolved code
location (which sounds like should be improved).
To clarify this, I propose we use the term "Location Specification",
with shorthand "locaction spec", when we're talking about the user
input, the argument or arguments that is/are passed to commands to
instruct GDB how to find locations of interest. This is distinct from
the actual code locations in the program, which are what GDB finds
based on the user-specified location spec. Then use "location
specification or the shorter "location spec" thoughout instead of
"location" when we're talking about the user input.
Thus, this commit does the following:
- renames the "Specify Location" section of the manual to "Location
Specifications".
- It then introduces the term "Location Specification", with
corresponding shorthand "location spec", as something distinct from
an actual code location in the program. It explains what a concrete
code location is. It explains that a location specification may be
incomplete, and that may match multiple code locations in the
program, or no code location at all. It gives examples. Some
pre-existing examples were moved from the "Set Breaks" section, and
a few new ones that didn't exist yet were added. I think it is
better to have these centralized in this "Location Specification"
section, since all the other commands that accept a location spec
have an xref that points there.
- Goes through the manual, and where "@var{location}" was used for a
command argument, updated it to say "@var{locspec}" instead. At the
same time, tweaks the description of the affected commands to
describe what happens when the location spec resolves to more than
one location. Most commands just did not say anything about that.
One command -- "maint agent -at @var{location}" -- currently says it
accepts a "location", suggesting it can accept address and explicit
locations too, but that's incorrect. In reality, it only accepts
linespecs, so fix it accordingly.
One MI command -- "-trace-find line" -- currently says it accepts a
"line specification", but it can accept address and explicit
locations too, so fix it accordingly.
Special thanks goes to Eli Zaretskii for reviews and rewording
suggestions.
Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b
Doing a 32-bit build with "--enable-targets=all --disable-sim" fails to link
properly.
--
loongarch-tdep.o: In function `loongarch_gdbarch_init':
binutils-gdb/gdb/loongarch-tdep.c:443: undefined reference to `loongarch_r_normal_name'
loongarch-tdep.o: In function `loongarch_fetch_instruction':
binutils-gdb/gdb/loongarch-tdep.c:37: undefined reference to `loongarch_insn_length'
loongarch-tdep.o: In function `loongarch_scan_prologue(gdbarch*, unsigned long long, unsigned long long, frame_info*, trad_frame_cache*) [clone .isra.4]':
binutils-gdb/gdb/loongarch-tdep.c:87: undefined reference to `loongarch_insn_length'
binutils-gdb/gdb/loongarch-tdep.c:88: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:89: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:90: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:91: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:92: undefined reference to `loongarch_decode_imm'
--
Given the list of 64-bit BFD files in
opcodes/Makefile.am:TARGET64_LIBOPCODES_CFILES, it looks like GDB's
ALL_TARGET_OBS list is including files that should be included in
ALL_64_TARGET_OBS instead.
This patch accomplishes this and enables a 32-bit build with
"--enable-targets=all --disable-sim" to complete.
Moving the bpf, tilegx and loongarch files to the correct list means GDB can
find the correct disassembler function instead of finding a null pointer.
We still need the "--disable-sim" switch (or "--enable-64-bit-bfd") to
make a 32-bit build with "--enable-targets=all" complete correctly
The following test fails on the armeb-gnu-eabi target:
FAIL: Unwind information for Armv8.1-M.Mainline PACBTI extension
This patch adjusts the expected output for big endian.
This fixes -Wpedantic warnings in chew.c. Conversion between function
and object pointers is not guaranteed. They can even be different
sizes, not that we're likely to encounter build machines like that
nowadays.
PR 29194
* doc/chew.c (pcu): New union typedef.
(dict_type, pc): Use it here. Adjust uses of pc.
(add_to_definition): Make "word" param a pcu. Adjust all uses
of function.
(stinst_type): Delete.
Catch out of memory.
* doc/chew.c: Include libibery.h.
(init_string_with_size, nextword): Replace malloc with xmalloc.
(newentry, add_to_definition): Likewise.
(catchar, catbuf): Replace realloc with xrealloc.
(add_intrinsic): Replace strdup with xstrdup.
* doc/local.mk (LIBIBERTY): Define.
(chew): Link against libiberty.
* Makefile.in: Regenerate.
This also removes some unused variables, and deletes support for the
"var" keyword which isn't used and was broken. (No means to set
variables, and add_var used push_number inconsistent with its use
elsewhere.)
* doc/chew.c: Move typedefs before variables, variables before
functions.
(die): Move earlier.
(word_type, sstack, ssp): Delete.
(dict_type): Delete var field.
(add_var): Delete.
(compile): Remove "var" support.
The zhinx extension is a sub-extension in zfinx, corresponding to
zfh extension but use GPRs instead of FPRs.
This patch expanded the zfh insn class define, since zfh and zhinx
use the same opcodes, thanks for Nelson's works.
changelog in V2: Add missing classes of 'zfh' and 'zhinx' in
"riscv_multi_subset_supports_ext".
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): New extensions.
(riscv_multi_subset_supports_ext): New extensions.
gas/ChangeLog:
* testsuite/gas/riscv/fp-zhinx-insns.d: New test.
* testsuite/gas/riscv/fp-zhinx-insns.s: New test.
include/ChangeLog:
* opcode/riscv.h (enum riscv_insn_class): New INSN classes.
opcodes/ChangeLog:
* riscv-opc.c: Modify INSN_CLASS.
Consider this command defined in Python (in the file test-cmd.py):
class test_cmd (gdb.Command):
"""
This is the first line.
Indented second line.
This is the third line.
"""
def __init__ (self):
super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE)
def invoke (self, arg, from_tty):
print ("In test-cmd")
test_cmd()
Now, within a GDB session:
(gdb) source test-cmd.py
(gdb) help test-cmd
This is the first line.
Indented second line.
This is the third line.
(gdb)
I think there's three things wrong here:
1. The leading blank line,
2. The trailing blank line, and
3. Every line is indented from the left edge slightly.
The problem of course, is that GDB is using the Python doc string
verbatim as its help text. While the user has formatted the help text
so that it appears clear within the .py file, this means that the text
appear less well formatted when displayed in the "help" output.
The same problem can be observed for gdb.Parameter objects in their
set/show output.
In this commit I aim to improve the "help" output for commands and
parameters.
To do this I have added gdbpy_fix_doc_string_indentation, a new
function that rewrites the doc string text following the following
rules:
1. Leading blank lines are removed,
2. Trailing blank lines are removed, and
3. Leading whitespace is removed in a "smart" way such that the
relative indentation of lines is retained.
With this commit in place the above example now looks like this:
(gdb) source ~/tmp/test-cmd.py
(gdb) help test-cmd
This is the first line.
Indented second line.
This is the third line.
(gdb)
Which I think is much neater. Notice that the indentation of the
second line is retained. Any blank lines within the help text (not
leading or trailing) will be retained.
I've added a NEWS entry to note that there has been a change in
behaviour, but I didn't update the manual. The existing manual is
suitably vague about how the doc string is used, so I think the new
behaviour is covered just as well by the existing text.
Make use of gdb::unique_xmalloc_ptr<char> to hold the documentation
string in cmdpy_init (when creating a custom GDB command in Python).
I think this is all pretty straight forward, the only slight weirdness
is the removal of the call to free toward the end of this function.
Prior to this commit, if an exception was thrown after the GDB command
was created then we would (I think) end up freeing the documentation
string even though the command would remain registered with GDB, which
would surely lead to undefined behaviour.
After this commit we release the doc string at the point that we hand
it over to the command creation routines. If we throw _after_ the
command has been created within GDB then the doc string will be left
live. If we throw during the command creation itself (either from
add_prefix_cmd or add_cmd) then it is up to those functions to free
the doc string (I suspect we don't, but I think in general the
commands are pretty bad at cleaning up after themselves, so I don't
think this is a huge problem).
Luis noticed that "maint print arc" would crash, because the command
handler did not find "show" in the command name, violating an
invariant. This patch fixes the bug by changing the registration to
use add_basic_prefix_cmd instead.
While working on another patch[1] I had need to touch this code in
i386-dis.c:
ins->obufp = ins->mnemonicendp;
for (i = strlen (ins->obuf) + prefix_length; i < 6; i++)
oappend (ins, " ");
oappend (ins, " ");
(*ins->info->fprintf_styled_func)
(ins->info->stream, dis_style_mnemonic, "%s", ins->obuf);
What this code does is add whitespace after the instruction mnemonic
and before the instruction operands.
The problem I ran into when working on this code can be seen by
assembling this input file:
.text
nop
retq
Now, when I disassemble, here's the output. I've replaced trailing
whitespace with '_' so that the issue is clearer:
Disassembly of section .text:
0000000000000000 <.text>:
0: 90 nop
1: c3 retq___
Notice that there's no trailing whitespace after 'nop', but there are
three spaces after 'retq'!
What happens is that instruction mnemonics are emitted into a buffer
instr_info::obuf, then instr_info::mnemonicendp is setup to point to
the '\0' character at the end of the mnemonic.
When we emit the whitespace, this is then added starting at the
mnemonicendp position. Lets consider 'retq', first the buffer is
setup like this:
'r' 'e' 't' 'q' '\0'
Then we add whitespace characters at the '\0', converting the buffer
to this:
'r' 'e' 't' 'q' ' ' ' ' ' ' '\0'
However, 'nop' is actually an alias for 'xchg %rax,%rax', so,
initially, the buffer is setup like this:
'x' 'c' 'h' 'g' '\0'
Then in NOP_Fixup we spot that we have an instruction that is an alias
for 'nop', and adjust the buffer to this:
'n' 'o' 'p' '\0' '\0'
The second '\0' is left over from the original buffer contents.
However, when we rewrite the buffer, we don't afjust mnemonicendp,
which still points at the second '\0' character.
Now, when we insert whitespace we get:
'n' 'o' 'p' '\0' ' ' ' ' ' ' ' ' '\0'
Notice the whitespace is inserted after the first '\0', so, when we
print the buffer, the whitespace is not printed.
The fix for this is pretty easy, I can change NOP_Fixup to adjust
mnemonicendp, but now a bunch of tests start failing, we now produce
whitespace after the 'nop', which the tests don't expect.
So, I could update the tests to expect the whitespace....
...except I'm not a fan of trailing whitespace, so I'd really rather
not.
Turns out, I can pretty easily update the whitespace emitting code to
spot instructions that have zero operands and just not emit any
whitespace in this case. So this is what I've done.
I've left in the fix for NOP_Fixup, I think updating mnemonicendp is
probably a good thing, though this is not really required any more.
I've then updated all the tests that I saw failing to adjust the
expected patterns to account for the change in whitespace.
[1] https://sourceware.org/pipermail/binutils/2022-April/120610.html
bfd_hostptr_t is defined as a type large enough to hold either a long
or a pointer. It mostly appears in the coff backend code in casts.
include/coff/internal.h struct internal_syment and union
internal_auxent have the only uses in data structures, where
comparison with include/coff/external.h and other code reveals that
the type only needs to be large enough for a 32-bit integer or a
pointer. That should mean replacing with uintptr_t is OK.
Requiring C99 means that uses of bfd_uint64_t can be replaced with
uint64_t, and similarly for bfd_int64_t, BFD_HOST_U_64_BIT, and
BFD_HOST_64_BIT. This patch does that, removes #ifdef BFD_HOST_*
and tidies a few places that print 64-bit values.
gprofng/ChangeLog
2022-05-26 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* libcollector/configure.ac: Use AC_MSG_WARN instead of AC_MSG_ERROR
* libcollector/configure: Rebuild.
MASM doesn't support the separate operand form; the modifier belongs
after the instruction instead. Accept this form alongside the original
(now legacy) one. Short of having access to a MASM version to actually
check in how far "after the instruction" is a precise statement in their
documentation, allow both that and the SDM mandated form where the
modifier is on the last register operand (with a possible immediate
operand following).
Sadly the split out function, at least for the time being, needs to cast
away constness at some point, as the two callers disagree in this
regard.
Adjust some, but not all of the testcases.
As a preparatory step to allowing proper non-operand forms of specifying
embedded rounding / SAE, convert the internal representation to non-
operand form. While retaining properties (and in a few cases perhaps
providing more meaningful diagnostics), this means doing away with a few
hundred standalone templates, thus - as a nice side effect - reducing
memory consumption / cache occupancy.
MASM doesn't consider {sae} and alike a separate operand; it is attached
to the last register operand instead, just like spelled out by the SDM.
Make the disassembler follow this first, before also adjusting the
assembler (such that it'll be easy to see that the assembler change
doesn't alter generated code).
MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
DWORD PTR) and alike are to be used there instead. Accept these forms
alongside the original (now legacy) ones.
Acceptance of the original {1to<n>} operand suffix is retained both for
backwards compatibility and to disambiguate VFPCLASSP{S,D,H} and vector
conversions with shrinking element sizes. I have no insight (yet) into
how MASM expects those to be disambiguated.
Adjust some, but not all of the testcases.
MASM doesn't support the {1to<n>} form; DWORD BCST (paralleling
DWORD PTR) and alike are to be used there instead. Make the disassembler
follow this first, before also adjusting the assembler (such that it'll
be easy to see that the assembler change doesn't alter generated code).
For VFPCLASSP{S,D,H} and vector conversions with shrinking element sizes
the original {1to<n>} operand suffix is retained, to disambiguate
output. I have no insight (yet) into how MASM expects those to be
disambiguated.
ld:
configure.tgt (cris-*-*, crisv32-*-* sans *-aout and *-linux): Unless
specified through the --enable-* -option, default to
--no-warn-rwx-segment.
Change-Id: I846bcd3e6762da807b17215a9fe337461ea0d710
In the now-historical CRIS glibc port, the default stack permission
was no-exec as in "#define DEFAULT_STACK_PERMS (PF_R|PF_W)", and the
gcc port only emits the executable-stack marker when needed; when
emitting code needing it. In other words, the binutils setting
mismatches. It doesn't matter much, except being confusing and
defaulting to "off" is more sane.
ld:
* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Switch to 0
for cris*-*-*.
bfd:
* elf32-cris.c (elf_backend_default_execstack): Define to 0.
Change-Id: I52f37598f119b19111c7a6546c00a627fca0f396
The previous patch ensured that partial symbols are read before calling
most of the quick_function's methods.
The psymbol_functions class has the require_partial_symbols method which
serves this exact purpose, and does not need to do it anymore.
This patch renames this method to partial_symbols and makes it an accessor
which asserts that partial symbols have been read at this point.
Regression tested on x86_64-linux.
The recent DWARF indexer rewrite introduced a regression when debugging
a forking program.
Here is a way to reproduce the issue (there might be other ways, but one
is enough and this one mimics the situation we encountered). Consider a
program which forks, and the child loads a shared library and calls a
function in this shared library:
if (fork () == 0)
{
void *solib = dlopen (some_solib, RTLD_NOW);
void (*foo) () = dlsym (some_solib, "foo");
foo ();
}
Suppose that this program is compiled without debug info, but the shared
library it loads has debug info enabled.
When debugging such program with the following options:
- set detach-on-fork off
- set follow-fork-mode child
we see something like:
(gdb) b foo
Function "foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (foo) pending.
(gdb) run
Starting program: a.out
[Attaching after process 19720 fork to child process 19723]
[New inferior 2 (process 19723)]
[Switching to process 19723]
Thread 2.1 "a.out" hit Breakpoint 1, 0x00007ffff7fc3101 in foo () from .../libfoo.so
(gdb) list
Fatal signal: Segmentation fault
----- Backtrace -----
0x55a278f77d76 gdb_internal_backtrace_1
../../gdb/bt-utils.c:122
0x55a278f77f83 _Z22gdb_internal_backtracev
../../gdb/bt-utils.c:168
0x55a27940b83b handle_fatal_signal
../../gdb/event-top.c:914
0x55a27940bbb1 handle_sigsegv
../../gdb/event-top.c:987
0x7effec0343bf ???
/build/glibc-sMfBJT/glibc-2.31/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x55a27924c9d3 _ZNKSt15__uniq_ptr_implI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE6_M_ptrEv
/usr/include/c++/9/bits/unique_ptr.h:154
0x55a279248bc9 _ZNKSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterE3getEv
/usr/include/c++/9/bits/unique_ptr.h:361
0x55a2792ae718 _ZN27dwarf2_base_index_functions23find_last_source_symtabEP7objfile
../../gdb/dwarf2/read.c:3164
0x55a279afb93e _ZN7objfile23find_last_source_symtabEv
../../gdb/symfile-debug.c:139
0x55a279aa3040 _Z20select_source_symtabP6symtab
../../gdb/source.c:365
0x55a279aa22a1 _Z34set_default_source_symtab_and_linev
../../gdb/source.c:268
0x55a27903c44c list_command
../../gdb/cli/cli-cmds.c:1185
0x55a279051233 do_simple_func
../../gdb/cli/cli-decode.c:95
0x55a27905f221 _Z8cmd_funcP16cmd_list_elementPKci
../../gdb/cli/cli-decode.c:2514
0x55a279c3b0ba _Z15execute_commandPKci
../../gdb/top.c:660
0x55a27940a6c3 _Z15command_handlerPKc
../../gdb/event-top.c:598
0x55a27940b032 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE
../../gdb/event-top.c:797
0x55a279caf401 tui_command_line_handler
../../gdb/tui/tui-interp.c:278
0x55a279409098 gdb_rl_callback_handler
../../gdb/event-top.c:230
0x55a279ed5df2 rl_callback_read_char
../../../readline/readline/callback.c:281
0x55a279408bd8 gdb_rl_callback_read_char_wrapper_noexcept
../../gdb/event-top.c:188
0x55a279408de7 gdb_rl_callback_read_char_wrapper
../../gdb/event-top.c:205
0x55a27940a061 _Z19stdin_event_handleriPv
../../gdb/event-top.c:525
0x55a27a23771e handle_file_event
../../gdbsupport/event-loop.cc:574
0x55a27a237f5f gdb_wait_for_event
../../gdbsupport/event-loop.cc:700
0x55a27a235d81 _Z16gdb_do_one_eventv
../../gdbsupport/event-loop.cc:237
0x55a2796c2ef0 start_event_loop
../../gdb/main.c:418
0x55a2796c3217 captured_command_loop
../../gdb/main.c:478
0x55a2796c717b captured_main
../../gdb/main.c:1340
0x55a2796c7217 _Z8gdb_mainP18captured_main_args
../../gdb/main.c:1355
0x55a278d0b381 main
../../gdb/gdb.c:32
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
The first issue observed is in the message printed when hitting the
breakpoint. It says that there was a break in the .so file as if there
was no debug info associated with it, but there is. Later, if we try to
display the source where the execution stopped, we have a segfault.
Note that not having the debug info on the main binary is not strictly
required to encounter some issues, it only is to encounter the segfault.
If the main binary has debug information, GDB shows some source form the
main binary, unrelated to where we stopped.
The core of the issue is that GDB never loads the psymtab for the
library. It is not loaded when we first see the .so because in case of
detach-on-fork off, follow-fork-mode child, infrun.c sets
child_inf->symfile_flags = SYMFILE_NO_READ to delay the psymtab loading
as much as possible. If we compare to what was done to handle this
before the new indexer was activated, the psymatb construction for the
shared library was done under
psymbol_functions::expand_symtabs_matching:
bool
psymbol_functions::expand_symtabs_matching (...)
{
for (partial_symtab *ps : require_partial_symbols (objfile))
...
}
The new indexer's expand_symtabs_matching callback does not have a call
to the objfile's require_partial_symbols, so if the partial symbol table
is not loaded at this point, there is no mechanism to fix this.
Instead of requiring each implementation of the quick_functions to check
that partial symbols have been read, I think it is safer to enforce this
when calling the quick functions. The general pattern for calling the
quick functions is:
for (auto *iter : qf)
iter->the_actual_method_call (...)
This patch proposes to wrap the access of the `qf` field with an accessor
which ensures that partial symbols have been read before iterating:
qf_require_partial_symbols. All calls to quick functions are updated
except:
- quick_functions::dump
- quick_functions::read_partial_symbols (from
objfile::require_partial_symbols)
- quick_functions::can_lazily_read_symbols and quick_functions::has_symbols
(from objfile::has_partial_symbols)
Regression tested on x86_64-gnu-linux.
Change-Id: I39a13a937fdbaae613a5cf68864b021000554546
PR gdb/29128 points out a crash in the new DWARF index code. This
happens if the aranges for a CU claims a PC, but the symtab that is
created during CU expansion does not actually contain the PC. This
can only occur due to bad debuginfo, but at the same time, gdb should
not crash.
This patch fixes the bug and further merges some code into
dwarf2_base_index_functions. This merger helps prevent the same issue
from arising from the other index implementations.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29128
After DWARF has been scanned, the cooked index code does a
"finalization" step in a worker thread. This step combines all the
index entries into a single master list, canonicalizes C++ names, and
splits Ada names to synthesize package names.
While this step is run in the background, gdb will wait for the
results in some situations, and it turns out that this step can be
slow. This is PR symtab/29105.
This can be sped up by parallelizing, at a small memory cost. Now
each index is finalized on its own, in a worker thread. The cost
comes from name canonicalization: if a given non-canonical name is
referred to by multiple indices, there will be N canonical copies (one
per index) rather than just one.
This requires changing the users of the index to iterate over multiple
results. However, this is easily done by introducing a new "chained
range" class.
When run on gdb itself, the memory cost seems rather low -- on my
current machine, "maint space 1" reports no change due to the patch.
For performance testing, using "maint time 1" and "file" will not show
correct results. That approach measures "time to next prompt", but
because the patch only affects background work, this shouldn't (and
doesn't) change. Instead, a simple way to make gdb wait for the
results is to set a breakpoint.
Before:
$ /bin/time -f%e ~/gdb/install/bin/gdb -nx -q -batch \
-ex 'break main' /tmp/gdb
Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
2.00
After:
$ /bin/time -f%e ./gdb/gdb -nx -q -batch \
-ex 'break main' /tmp/gdb
Breakpoint 1 at 0x43ec30: file ../../binutils-gdb/gdb/gdb.c, line 28.
0.65
Regression tested on x86-64 Fedora 34.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
Copy initialisation over from the elf.em before_parse. Commit
ba951afb99 2022-05-03 changed behaviour on arm and score regarding
exec stack. This patch restores the previous behaviour.
* emultempl/aarch64elf.em (before_parse): Init separate_code,
warn_execstack, no_warn_rwx_segments and default_execstack.
* emultempl/armelf.em (before_parse): Likewise.
* emultempl/scoreelf.em (before_parse): Likewise.
* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Return
true for arm and nacl.
Whilst reviewing Luis' proposed change to s_arm_unwind_save_mixed
yesterday I noticed that we were making use of __builting_clzl
directly within the main function, which is not guaranteed to be
portable. Whilst studying the code further, I also realized that it
could be rewritten without using it and also reworked to remove a lot
of unnecessary iterations steps. So this patch does that (and also
removes the source of the warning that Luis was trying to fix).
Finally, with the rewrite we can also simplify the caller of this
routine as the new version can handle all the cases directly.
* config/tc-arm.c (s_arm_unwind_save_mixed): Rewrite without
using __builtin_clzl.
(s_arm_unwind_save): Simplify logic for simple/mixed register saves.
