Add a getter and a setter for a symtab's language. Remove the
corresponding macro and adjust all callers.
Change-Id: I9f4d840b11c19f80f39bac1bce020fdd1739e11f
Add a getter and a setter for a symtab's linetable. Remove the
corresponding macro and adjust all callers.
Change-Id: I159183fc0ccd8e18ab937b3c2f09ef2244ec6e9c
Add a getter and a setter for a symtab's compunit_symtab. Remove the
corresponding macro and adjust all callers.
For brevity, I chose the name "compunit" instead of "compunit_symtab"
the the field, getter and setter names. Since we are already in symtab
context, the _symtab suffix seems redundant.
Change-Id: I4b9b731c96e3594f7733e75af1e3d01bc0e4fe92
Add a getter and a setter for a compunit_symtab's macro table. Remove the
corresponding macro and adjust all callers.
Change-Id: I00615ea72d5ac43d9a865e941cb2de0a979c173a
Add a getter and a setter for a compunit_symtab's epilogue unwind valid flag.
Remove the corresponding macro and adjust all callers.
Change-Id: If3b68629d987767da9be7041a95d96dc34367a9a
Add a getter and a setter for a compunit_symtab's locations valid flag.
Remove the corresponding macro and adjust all callers.
Change-Id: I3e3cfba926ce62993d5b61814331bb3244afad01
Add a getter and a setter for a compunit_symtab's block line section. Remove
the corresponding macro and adjust all callers.
Change-Id: I3eb1a323388ad55eae8bfa45f5bc4a08dc3df455
Add a getter and a setter for a compunit_symtab's blockvector. Remove
the corresponding macro and adjust all callers.
Change-Id: I99484c6619dcbbea7c5d89c72aa660316ca62f64
Add a getter and a setter for a compunit_symtab's dirname. Remove the
corresponding macro and adjust all callers.
Change-Id: If2f39b295fd26822586485e04a8b8b5aa5cc9b2e
Add a getter and a setter for a compunit_symtab's producer. Remove the
corresponding macro and adjust all callers.
Change-Id: Ia1d6d8a0e247a08a21af23819d71e49b37d8931b
Add a getter and a setter for a compunit_symtab's debugformat. Remove
the corresponding macro and adjust all callers.
Change-Id: I1667b02d5322346f8e23abd9f8a584afbcd75975
I think that most remaining uses of COMPUNIT_FILETABS intend to get the
primary filetab of the compunit_symtab specifically (and not to iterate
over all filetabs, for example, those cases would use compunit_filetabs,
which has been converted to compunit_symtab::filetabs), so replace mosts
uses with compunit_symtab::primary_filetab.
In jit.c, function finalize_symtab, we can save the symtab object
returned by allocate_symtab and use it, it makes things simpler.
Change-Id: I4e51d6d4b40759de8768b61292e5e13c8eae2e38
Make compunit_filetabs, used to iterate a compunit_symtab's filetabs, a
method of compunit_symtab. The name filetabs conflicts with the current
name of the field. Rename the field to m_filetabs, since at this point
nothing outside of compunit_symtab uses it, so we should treat it as
private (even though it's not actually private). Rename the
last_filetab field to m_last_filetab as well (it's only used on
compunit_symtab::add_filetab).
Adjust the COMPUNIT_FILETABS macro to keep its current behavior of
returning the first filetab.
Change-Id: I537b553a44451c52d24b18ee1bfa47e23747cfc3
Add a method to set the primary filetab of the CU. This is currently
done in buildsym_compunit::end_symtab_with_blockvector.
Change-Id: I16c51a6b90a4cb4c0c5f183b0f2e12bc64b6fd74
Add a method to append a filetab/symtab to a compunit_symtab. There is
a single place where this is done currently, in allocate_symtab.
Change-Id: Ie86c6e34d175728173d1cffdce44acd6cff6c31d
Rust 1.53 (quite a while ago now) ungated the support for non-ASCII
identifiers. This didn't work in gdb. This is PR rust/20166.
This patch fixes the problem by allowing non-ASCII characters to be
considered as identifier components. It seemed simplest to just pass
them through -- doing any extra checking didn't seem worthwhile.
The new test also verifies that such characters are allowed in strings
and character literals as well. The latter also required a bit of
work in the lexer.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20166
In Rust, 'obj.f()' is a method call -- but '(obj.f)()' is a call of a
function-valued field 'f' in 'obj'. The Rust parser in gdb currently
gets this wrong. This is PR rust/24082.
The expression and Rust parser rewrites made this simple to fix --
simply wrapping a parenthesized expression in a new operation handles
it. This patch has a slight hack because I didn't want to introduce a
new exp_opcode enumeration constant just for this. IMO this doesn't
matter, since we should work toward removing dependencies on these
opcodes anyway; but let me know what you think of this.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24082
This started by noticing that the docs for 'winheight' are out of
date, the docs currently give a specific list of possible window
names. However, now that windows can be implemented in Python, it is
not possible to list all possible names.
I now link the user to a mechanism by which they can discover the
valid names for themselves at run time (by using 'info win'). That,
and the fact that gdb provides tab-completion of the name at the
command line, feels good enough.
Finally, I noticed that the docs for 'win info' don't explicitly say
that the name of the window is given in the output. This could
probably have been inferred, but given I'm now linking to this as a
mechanism to find the window name, I'd prefer to mention that the name
can be found in the output.
Now that we support horizontal window placement in the tui, it makes
sense to have 'info win' include the width, as well as the height, of
the currently visible windows.
That's what this commit does. Example output is now:
(gdb) info win
Name Lines Columns Focus
src 12 40 (has focus)
asm 12 41
status 1 80
cmd 11 80
I've added a NEWS entry, but the documentation was already suitably
vague, it just says that 'info win' displays the size of the visible
windows, so I don't think anything needs to be added there.
I've also added some tests, as far as I could find, the 'info win'
command was previously untested.
Don't abort for undefined symbol when finishing DT_RELR. Instead, skip
undefined symbol. Undefined symbol will be reported by relocate_section.
* elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Skip
undefined symbol in finishing phase.
This testcase triggers a stub sizing error with the patches applied
for PR28743 (commit 2f83249c13d8 and c804c6f98d34).
PR 28827
* testsuite/ld-powerpc/pr28827-1.s,
* testsuite/ld-powerpc/pr28827-1.d: New test.
* testsuite/ld-powerpc/powerpc.exp: Run it.
Current code detects the need for PT_GNU_EH_FRAME using a field set by
_bfd_elf_discard_section_eh_frame_hdr, which is called fairly late in
the linking process. Use the elf hash table eh_info instead, which is
set up earlier by size_dynamic_sections.
* elf-bfd.h (struct output_elf_obj_tdata): Delete eh_frame_hdr.
(elf_eh_frame_hdr): Don't define.
(_bfd_elf_discard_section_eh_frame_hdr): Update prototype.
* elf-eh-frame.c (_bfd_elf_discard_section_eh_frame_hdr): Delete
abfd parameter. Don't set elf_eh_frame_hdr.
* elf.c (elf_eh_frame_hdr): New function.
(get_program_header_size): Adjust elf_eh_frame_hdr call.
(_bfd_elf_map_sections_to_segments): Likewise.
IEEE754-1985 specifies the top bit of the mantissa as an indicator
of signalling vs. quiet NaN, but does not define the precise semantics.
Most architectures treat this bit as indicating quiet NaN, but legacy
(pre-R6) MIPS goes the other way and treats it as signalling NaN.
This used to be controlled by a macro that was only defined for MIPS.
This patch replaces the macro with a variable to track the current
semantics of the NaN bit and allows differentiation between older
(pre-R6) and and newer MIPS cores.
2022-02-01 Faraz Shahbazker <fshahbazker@wavecomp.com>
sim/common/ChangeLog:
* sim-fpu.c (_sim_fpu): New.
(pack_fpu, unpack_fpu): Allow reversal of quiet NaN semantics.
* sim-fpu.h (sim_fpu_state): New struct.
(_sim_fpu): New extern.
(sim_fpu_quiet_nan_inverted): New define.
sim/mips/ChangeLog:
* cp1.h (fcsr_NAN2008_mask, fcsr_NAN2008_shift): New.
* mips.igen (check_fpu): Select default quiet NaN mode
for legacy MIPS.
* sim-main.h (SIM_QUIET_NAN_NEGATED): Remove.
Remove emultempl/armcoff.em which has been unused after
commit 2ac93be706418f3b2aebeb22159a328023faed52
Author: Alan Modra <amodra@gmail.com>
Date: Mon Apr 16 20:33:36 2018 +0930
Remove arm-aout and arm-coff support
This also removes arm-netbsd (not arm-netbsdelf!), arm-openbsd, and
arm-riscix. Those targets weren't on the obsolete list but they are
all aout, and it doesn't make all that much sense to remove arm-aout
without removing them too.
* emultempl/armcoff.em: Removed.
This commit includes the JIT object's symfile address in the names of
objfiles created by JIT reader API (e.g., << JIT compiled code at
0x7ffd8a0c77a0 >>). This allows one to at least differentiate one from
another.
The address is the one that the debugged program has put in
jit_code_entry::symfile_addr, and that the JIT reader's read function
receives. As we can see in gdb.base/jit-reader-host.c and
gdb.base/jit-reader.c, that may not be the actual value of where the
JIT-ed code is. But it is a value chosen by the author of the JIT
engine and the JIT reader, so including this value in the objfile name
may help them correlate the JIT objfiles created by with their logs /
data structures.
To access this field, we need to pass down a reference to the
jit_code_entry. So make jit_dbg_reader_data a structure (instead of an
alias for a CORE_ADDR) that includes the address of the code entry in
the inferior's address space (the previous meaning of
jit_dbg_reader_data) plus a reference to the jit_code_entry as read into
GDB's address space. And while at it, pass down the gdbarch, so that we
don't have to call target_gdbarch.
Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
Change-Id: Ib26c4d1bd8de503d651aff89ad2e500cb312afa5
Currently, "ptype" of an Ada unchecked union may show a
compiler-generated wrapper structure in its output. It's more
Ada-like to elide this structure, which is what this patch implements.
It turned out to be simplest to reuse a part of print_variant_clauses
for this.
As this is Ada-specific, and Joel already reviewed it internally, I am
going to check it in.
I noticed that host_hex_value is redundant, because gdbsupport already
has fromhex. This patch removes the former in favor of the latter.
Regression tested on x86-64 Fedora 34.
The Linux kernel usually ouputs symbol+offset instead of plain code
addresses these days, to avoid leaking ASLR secrets and to handle
dynamically loaded modules.
Converting those with addr2line is somewhat involved: it requires
looking up the symbol first using nm and then manually compute the
offset, and then pass it to addr2line.
This patch implements the necessary steps directly in addr2line,
by looking up the symbol (with demangling if needed) and computing
the offset.
It's possible that a symbol is ambigious with a hex number. In this
case it uses the symbol lookup if the string contains a +. When it isn't
ambigious the + is optional.
Add R_X86_64_GOT32, R_X86_64_GOT64, R_X86_64_GOTPCREL64 and
R_X86_64_GOTPLT64 to X86_64_GOT_TYPE_P to cover more GOT relocations.
PR ld/28858
* elfxx-x86.h (X86_64_GOT_TYPE_P): Add R_X86_64_GOT32,
R_X86_64_GOT64, R_X86_64_GOTPCREL64 and R_X86_64_GOTPLT64.
Starting with commit
commit 1da5d0e664e362857153af8682321a89ebafb7f6
Date: Tue Jan 4 08:02:24 2022 -0700
Change how Python architecture and language are handled
we see a failure in gdb.threads/killed-outside.exp:
...
Executing on target: kill -9 16622 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 16622
continue
Continuing.
Couldn't get registers: No such process.
(gdb) [Thread 0x7ffff77c2700 (LWP 16626) exited]
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)
This is not a regression but a failure due to a change in GDB's
output. Prior to the aforementioned commit, GDB has been printing the
"Couldn't get registers: No such process." message twice. The second
one came from
(top-gdb) bt
#0 amd64_linux_nat_target::fetch_registers (this=0x555557f31440 <the_amd64_linux_nat_target>, regcache=0x555558805ce0, regnum=16) at /gdb-up/gdb/amd64-linux-nat.c:225
#1 0x000055555640ac5f in target_ops::fetch_registers (this=0x555557d636d0 <the_thread_db_target>, arg0=0x555558805ce0, arg1=16) at /gdb-up/gdb/target-delegates.c:502
#2 0x000055555641a647 in target_fetch_registers (regcache=0x555558805ce0, regno=16) at /gdb-up/gdb/target.c:3945
#3 0x0000555556278e68 in regcache::raw_update (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:587
#4 0x0000555556278f14 in readable_regcache::raw_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:601
#5 0x00005555562792aa in readable_regcache::cooked_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:690
#6 0x000055555627965e in readable_regcache::cooked_read_value (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:748
#7 0x0000555556352a37 in sentinel_frame_prev_register (this_frame=0x555558181090, this_prologue_cache=0x5555581810a8, regnum=16) at /gdb-up/gdb/sentinel-frame.c:53
#8 0x0000555555fa4773 in frame_unwind_register_value (next_frame=0x555558181090, regnum=16) at /gdb-up/gdb/frame.c:1235
#9 0x0000555555fa420d in frame_register_unwind (next_frame=0x555558181090, regnum=16, optimizedp=0x7fffffffd570, unavailablep=0x7fffffffd574, lvalp=0x7fffffffd57c, addrp=0x7fffffffd580,
realnump=0x7fffffffd578, bufferp=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1143
#10 0x0000555555fa455f in frame_unwind_register (next_frame=0x555558181090, regnum=16, buf=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1199
#11 0x00005555560178e2 in i386_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/i386-tdep.c:1972
#12 0x0000555555cd2b9d in gdbarch_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/gdbarch.c:3007
#13 0x0000555555fa3a5b in frame_unwind_pc (this_frame=0x555558181090) at /gdb-up/gdb/frame.c:948
#14 0x0000555555fa7621 in get_frame_pc (frame=0x555558181160) at /gdb-up/gdb/frame.c:2572
#15 0x0000555555fa7706 in get_frame_address_in_block (this_frame=0x555558181160) at /gdb-up/gdb/frame.c:2602
#16 0x0000555555fa77d0 in get_frame_address_in_block_if_available (this_frame=0x555558181160, pc=0x7fffffffd708) at /gdb-up/gdb/frame.c:2665
#17 0x0000555555fa5f8d in select_frame (fi=0x555558181160) at /gdb-up/gdb/frame.c:1890
#18 0x0000555555fa5bab in lookup_selected_frame (a_frame_id=..., frame_level=-1) at /gdb-up/gdb/frame.c:1720
#19 0x0000555555fa5e47 in get_selected_frame (message=0x0) at /gdb-up/gdb/frame.c:1810
#20 0x0000555555cc9c6e in get_current_arch () at /gdb-up/gdb/arch-utils.c:848
#21 0x000055555625b239 in gdbpy_before_prompt_hook (extlang=0x555557451f20 <extension_language_python>, current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ")
at /gdb-up/gdb/python/python.c:1063
#22 0x0000555555f7cfbb in ext_lang_before_prompt (current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ") at /gdb-up/gdb/extension.c:922
#23 0x0000555555f7d442 in std::_Function_handler<void (char const*), void (*)(char const*)>::_M_invoke(std::_Any_data const&, char const*&&) (__functor=...,
__args#0=@0x7fffffffd900: 0x555557f4d890 <top_prompt+16> "(gdb) ") at /usr/include/c++/7/bits/std_function.h:316
#24 0x0000555555f752dd in std::function<void (char const*)>::operator()(char const*) const (this=0x55555817d838, __args#0=0x555557f4d890 <top_prompt+16> "(gdb) ")
at /usr/include/c++/7/bits/std_function.h:706
#25 0x0000555555f75100 in gdb::observers::observable<char const*>::notify (this=0x555557f49060 <gdb::observers::before_prompt>, args#0=0x555557f4d890 <top_prompt+16> "(gdb) ")
at /gdb-up/gdb/../gdbsupport/observable.h:150
#26 0x0000555555f736dc in top_level_prompt () at /gdb-up/gdb/event-top.c:444
#27 0x0000555555f735ba in display_gdb_prompt (new_prompt=0x0) at /gdb-up/gdb/event-top.c:411
#28 0x00005555564611a7 in tui_on_command_error () at /gdb-up/gdb/tui/tui-interp.c:205
#29 0x0000555555c2173f in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/7/bits/std_function.h:316
#30 0x0000555555e10c20 in std::function<void ()>::operator()() const (this=0x5555580f9028) at /usr/include/c++/7/bits/std_function.h:706
#31 0x0000555555e10973 in gdb::observers::observable<>::notify() const (this=0x555557f48d20 <gdb::observers::command_error>) at /gdb-up/gdb/../gdbsupport/observable.h:150
#32 0x00005555560e9b3f in start_event_loop () at /gdb-up/gdb/main.c:438
#33 0x00005555560e9bcc in captured_command_loop () at /gdb-up/gdb/main.c:481
#34 0x00005555560eb616 in captured_main (data=0x7fffffffddd0) at /gdb-up/gdb/main.c:1348
#35 0x00005555560eb67c in gdb_main (args=0x7fffffffddd0) at /gdb-up/gdb/main.c:1363
#36 0x0000555555c1b6b3 in main (argc=12, argv=0x7fffffffded8) at /gdb-up/gdb/gdb.c:32
Commit 1da5d0e664 eliminated the call to 'get_current_arch'
in 'gdbpy_before_prompt_hook'. Hence, the second instance of
"Couldn't get registers: No such process." does not appear anymore.
Fix the failure by updating the regular expression in the test.
Supporting -static-pie on PowerPC64 requires the linker to properly
treat SHN_ABS symbols for cases like glibc's _nl_current_LC_CTYPE_used
absolute symbol. I've been slow to fix the linker on powerpc because
there is some chance that this will break some shared libraries or
PIEs.
bfd/
* elf64-ppc.c (ppc64_elf_check_relocs): Consolidate local sym
handling code. Don't count dyn relocs against non-dynamic
absolute symbols.
(dec_dynrel_count): Adjust to suit.
(ppc64_elf_edit_toc): Don't remove entries for absolute symbols
when pic.
(allocate_got): Don't allocate space for got relocs against
non-dynamic absolute syms.
(ppc64_elf_layout_multitoc): Likewise.
(got_and_plt_relr): Likewise.
(ppc64_elf_size_dynamic_sections): Likewise for local got.
(got_and_plt_relr_for_local_syms): Likewise.
(ppc64_elf_size_stubs): Don't allocate space for relr either.
(ppc64_elf_relocate_section): Don't write relocs against non-dynamic
absolute symbols. Don't optimise got and toc code sequences
loading absolute symbol entries.
ld/
* testsuite/ld-powerpc/abs-reloc.s,
* testsuite/ld-powerpc/abs-static.d,
* testsuite/ld-powerpc/abs-static.r,
* testsuite/ld-powerpc/abs-pie.d,
* testsuite/ld-powerpc/abs-pie.r,
* testsuite/ld-powerpc/abs-shared.d,
* testsuite/ld-powerpc/abs-shared.r,
* testsuite/ld-powerpc/abs-pie-relr.d,
* testsuite/ld-powerpc/abs-pie-relr.r,
* testsuite/ld-powerpc/abs-shared-relr.d,
* testsuite/ld-powerpc/abs-shared-relr.r: New tests.
* testsuite/ld-powerpc/powerpc.exp: Run them.
The formatting of the help text for 'help set extended-prompt' and
'help show extended-prompt' is a little off.
Here's the offending snippet:
Substitutions are applied to VALUE to compute the real prompt.
The currently defined substitutions are:
\[ Begins a sequence of non-printing characters.
\\ A backslash.
\] Ends a sequence of non-printing characters.
\e The ESC character.
Notice that the line for '\[' is indented more that the others.
Turns out this is due to how we build this help text, something which
is done in Python. We extended a classes __doc__ string with some
dynamically generated text.
The classes doc string looks like this:
"""Set the extended prompt.
Usage: set extended-prompt VALUE
Substitutions are applied to VALUE to compute the real prompt.
The currently defined substitutions are:
"""
Notice the closing """ are in a line of their own, and include some
white space just before. It's this extra white space that's causing
the problem.
Fix the formatting issue by moving the """ to the end of the previous
line. I then add the extra newline in at the point where the doc
string is merged with the dynamically generated text.
Now everything lines up correctly.
While working on the fix for PR cli/28665 (see previous couple of
commits), I was playing with making a change in the linespec parsing
code. Specifically, I was thinking about whether the spec_string for
LINESPEC_LOCATION locations should ever be nullptr.
I made a change to prevent the spec_string from ever being nullptr,
tested gdb, and saw no regressions.
However, as part of this work I was reviewing how the breakpoint code
handles this case (spec_string being nullptr), and spotted that in
parse_breakpoint_sals the nullptr case is specifically handled, so
changing this should have caused a regression. But I didn't see one.
So, this commit adds a comment in location.c mentioning that the
nullptr case is (a) not an oversight, and (b) is required. Then I add
a new test to gdb.base/break.exp that ensures a change in this area
will cause a regression.
This test passes on current gdb, but with my modified (and broken)
gdb, the test would fail.
