| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add a new function reset_compunit_symtab.
|
|
|
|
This reverts commit 70e839550684896cdc581f28c4e948e4ff5ff6fe.
|
|
|
|
|
|
|
|
|
|
|
|
When looking up a variable, make sure its type is also marked as interesting.
|
|
When calling psymbol_functions::find_pc_sect_psymtab, we do not end up with an
actual symbol that we can declare interesting, so go find it.
|
|
|
|
When adding a partial symbol for an enum value, we try to find the section
offset for the enum itself rather than the enum value. This fails if the
parent die is not set. Fix that.
|
|
|
|
Use the interesting_symbols vector to filter the DIEs that we process when
doing read_file_scope.
At this point we start to get the benefit of lazy expansion:
...
$ time gdb -q -iex "maint set lazy-expand-symtab 0" -batch \
lto/cc1 -ex "b do_rpo_vn"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
real: 5.69
user: 5.47
system: 0.20
...
and with:
...
$ time gdb -q -iex "maint set lazy-expand-symtab 1" -batch \
lto/cc1 -ex "b do_rpo_vn"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
real: 2.75
user: 2.71
system: 0.10
...
|
|
Make the vector interesting_symbols available during full symbols expansion.
|
|
|
|
Initialize sect_off field of partial_tab using the sect_offset of the
top-level DIE of the partial_symbol.
|
|
Initially, we added a sect_off field to partial_symbol, but that turned out
to make the bcache aspect of partial symbols ineffective, changing the
"percentage of duplicates" for "partial symbol cache" as reported by "maint
print statistics" from 95% to 0%.
This showed up both as a slow down and more memory usage.
At least parts of the slow down could possibly be addressed by removing the
bcache aspect entirely (given that there are no duplicates), but that wouldn't
address the increase in memory usage.
Instead, implement the sect_off field as a side table.
|
|
Declare lazy_expand_symtab_p.
Declare directly in .c file(s) instead of header file for now, to speed up
rebuilding.
|
|
Enable lazy symtab expansion by default.
Should be the last patch, but moved earlier to make development
easier.
|
|
Add variable to enable lazy symbol table expansion.
Set to false for now, to enable gradual introduction of implementation.
Make user-settable using "maint set/show lazy-expand-symtab on/off".
|
|
|
|
|
|
|
|
|
|
When running test-case gdb.base/info-macros.exp, I run into:
...
PASS: gdb.base/info-macros.exp: info macro --
PASS: gdb.base/info-macros.exp: info macro --
DUPLICATE: gdb.base/info-macros.exp: info macro --
PASS: gdb.base/info-macros.exp: info macro --
...
These messages come from gdb_test calls using the following commands:
- "info macro --"
- "info macro -- "
- "info macro -- ".
Apparantly the test names get stripped of trailing whitespace, and the first
two end up identical.
Fix this by explicitly specifying an <EOL> after the trailing whitespace in
the test name, such that we have:
...
PASS: gdb.base/info-macros.exp: info macro --
PASS: gdb.base/info-macros.exp: info macro -- <EOL>
PASS: gdb.base/info-macros.exp: info macro -- <EOL>
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-06-24 Tom de Vries <tdevries@suse.de>
* gdb.base/info-macros.exp: Add <EOL> after trailing whitespace in
test names.
|
|
I found the following duplicates in gdb.base/argv0-symlink.exp:
...
DUPLICATE: gdb.base/argv0-symlink.exp: set print repeats 10000
DUPLICATE: gdb.base/argv0-symlink.exp: set print elements 10000
...
Fix these by using with_test_prefix "file symlink" / "dir symlink".
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-06-24 Tom de Vries <tdevries@suse.de>
* gdb.base/argv0-symlink.exp: Use with_test_prefix.
|
|
Power10 prefixed instructions must not cross 64-byte boundaries.
This is already handled.
However, on XCOFF, the csect must be updated to match the new
alignment.
* config/tc-ppc.c (md_assemble): Update ppc_current_csect
alignment when finding prefixed instructions.
|
|
If code tries to send a signal to itself, the callback layer ignores
it and forces the caller to handle it. This allows the sim to turn
that into an engine halt rather than actually killing the sim.
|
|
The cris linux syscall layers assume getpid returns a constant,
so add a custom function to provide that.
|
|
This will make it easier to emulate the syscall. If the kill target
is the sim itself, don't do anything. This forces the higher layers
to make a decision as to how to handle this event: like halting the
overall engine process.
|
|
|
|
We rewrite srcdir in subdir Makefiles that we generate from the common
parent dir since it points to the parent dir. Since @srcdir@ can be a
variety of formats (relative & absolute), switch to @abs_srcdir@ which
is a lot easier to adjust. Our use of srcdir in here should handle it.
|
|
On Ubuntu 20.04, when the debug info package for libc is not installed,
I get:
FAIL: gdb.base/info-types-c++.exp: info types
FAIL: gdb.base/info-types-c.exp: info types
The reason is that the output of info types is exactly:
(gdb) info types
All defined types:
File /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/info-types.c:
52: typedef enum {...} anon_enum_t;
45: typedef struct {...} anon_struct_t;
68: typedef union {...} anon_union_t;
28: typedef struct baz_t baz;
31: typedef struct baz_t * baz_ptr;
21: struct baz_t;
double
33: enum enum_t;
float
int
38: typedef enum enum_t my_enum_t;
17: typedef float my_float_t;
16: typedef int my_int_t;
54: typedef enum {...} nested_anon_enum_t;
47: typedef struct {...} nested_anon_struct_t;
70: typedef union {...} nested_anon_union_t;
30: typedef struct baz_t nested_baz;
29: typedef struct baz_t nested_baz_t;
39: typedef enum enum_t nested_enum_t;
19: typedef float nested_float_t;
18: typedef int nested_int_t;
62: typedef union union_t nested_union_t;
56: union union_t;
unsigned int
(gdb)
The lines we expect in the test contain an empty line at the end:
...
"62:\[\t \]+typedef union union_t nested_union_t;" \
"56:\[\t \]+union union_t;" \
"--optional" "\[\t \]+unsigned int" \
""]
This is written with the supposition that other files will be listed, so
an empty line will be included to separate the symbols from this file
from the next one. This empty line is not included when info-types.c is
the only file listed.
Fix this by rewriting gdb_test_lines to accept a single, plain tcl multiline
regexp, such that we can write:
...
"62:\[\t \]+typedef union union_t nested_union_t;" \
"56:\[\t \]+union union_t;(" \
"\[\t \]+unsigned int)?" \
"($|\r\n.*)"]
...
Tested affected test-cases:
- gdb.base/info-types-c.exp
- gdb.base/info-types-c++.exp
- gdb.base/info-macros.exp
- gdb.cp/cplusfuncs.exp
on x86_64-linux (openSUSE Leap 15.2), both with check and check-read1.
Also tested the first two with gcc-4.8.
Also tested on ubuntu 18.04.
gdb/testsuite/ChangeLog:
2021-06-23 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test_lines): Rewrite to accept single
multiline tcl regexp.
* gdb.base/info-types.exp.tcl: Update. Make empty line at end of
regexp optional.
* gdb.base/info-macros.exp: Update.
* gdb.cp/cplusfuncs.exp: Update.
|
|
|
|
Include header for hw funcs called, adjust prototype to match the
args given to it, and adjust cast to match the function.
|
|
There's been a prototype for this forever, but the implementation was
missing. Probably because there weren't any callers, but we'll start
using it to implement the kill function.
|
|
We've been generating the syscall/errno/open maps, but not the signal
map, even though we've been including them in the source constants.
|
|
Rather than hit the OS interface directly, use the existing callback
layer so the instantiator can decide behavior.
|
|
Move the unique configure flag to acinclude.m4 so the common code
can include it, then delete the rx configure logic entirely.
|
|
These ports only use the pieces that have been unified, so we can
merge them into the common configure script and get rid of their
unique one entirely.
We still compile & link separate run programs, and have dedicated
subdir Makefiles, but the configure script portion is merged.
|
|
Run black to fix this formatting.
gdb/ChangeLog:
* python/lib/gdb/__init__.py: Format.
Change-Id: I68ea306d1991bf7243b2c8aeeb11719d668851e5
|
|
do_target_wait has a wait_ptid parameter, to filter what ptid we wait
on. The sole caller of do_target_wait passes minus_one_ptid, meaning
"all ptids". So in practice, this parameter is not needed, remove it.
gdb/ChangeLog:
* infrun.c (do_target_wait): Remove wait_ptid parameter.
(fetch_inferior_event): Adjust.
Change-Id: I54119beb43db678e4b2081dc490f89e7ff878e74
|
|
If we have multiple registered unwinders, this will helps identify which
unwinder was chosen and make it easier to track down potential problems.
Unwinders have a mandatory name argument, which we can use in the
message.
First, make gdb._execute_unwinders return a tuple containing the name,
in addition to the UnwindInfo. Then, make pyuw_sniffer include the name
in the debug message.
I moved the debug message earlier. I think it's good to print it as
early as possible, so that we see it in case an assert is hit in the
loop below, for example.
gdb/ChangeLog:
* python/lib/gdb/__init__.py (_execute_unwinders): Return tuple
with name of chosen unwinder.
* python/py-unwind.c (pyuw_sniffer): Print name of chosen
unwinder in debug message.
Change-Id: Id603545b44a97df2a39dd1872fe1f38ad5059f03
|
|
Without that it is impossible to debug on riscv64.
gdb/
PR symtab/27999
* dwarf2/loc.c (decode_debug_loclists_addresses): Support
DW_LLE_start_end.
gdb/testsuite/
PR symtab/27999
* lib/dwarf.exp (start_end): New proc inside loclists.
* gdb.dwarf2/loclists-start-end.exp: New file.
* gdb.dwarf2/loclists-start-end.c: New file.
|
|
This test-case is intended to excercise this code in process_imported_unit_die:
...
/* We're importing a C++ compilation unit with tag DW_TAG_compile_unit
into another compilation unit, at root level. Regard this as a hint,
and ignore it. */
if (die->parent && die->parent->parent == NULL
&& per_cu->unit_type == DW_UT_compile
&& per_cu->lang == language_cplus)
return;
...
in the sense that the test-case should fail if the
"per_cu->lang == language_cplus" clause is removed.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-06-22 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/imported-unit-c.exp: New file.
|
|
The original discussion was here,
https://github.com/riscv/riscv-elf-psabi-doc/issues/184
After discussing with Kito Cheng, I think the addends of %pcrel_hi
and %pcrel_lo are both allowed in GNU toolchain. However, both of
the them mean the offset of symbols, rather than the pc address.
But the addends of %got_pcrel_hi and it's %pcrel_lo do not look
reasonable. I believe gcc won't generate the got patterns with
addends, so linker should report dangerous relocation errors,
in case the assembly code use them.
Another issue was here,
https://sourceware.org/pipermail/binutils/2021-June/116983.html
At the beginnig, I suppose %pcrel_hi and %pcrel_lo are valid only
when they are in the same input section. But Jim Wilson points out
that gcc may generate %hi and %lo in the different input sections,
when -freorder-blocks-and-partition option is used. So that a memory
references for a loop may have the %hi outside the loop, but the %lo
remain in the loop. However, it is hard to create the testcases,
to see if %pcrel_hi and %pcrel_lo have the same behavior.
Unfortunately, I notice that the current pcrel resolver cannot
work for the above case. For now we build a hash table for pcrel
at the start of riscv_elf_relocate_section, and then free the hash
at the end. But riscv_elf_relocate_section only handles an input
section at a time, so that means we can only resolve the %pcrel_hi
and %pcrel_lo which are in the same input section. Otherwise, like
the above case, we will report "%pcrel_lo missing matching %pcrel_hi"
for them. I have no plan to improve this in the short-term, so maybe
we can wait until someone meets the problem before we deal with it.
bfd/
* elfnn-riscv.c (riscv_pcrel_hi_reloc): Added field to store
the original relocation type, in case the type is converted to
R_RISCV_HI20.
(riscv_pcrel_lo_reloc): Removed unused name field.
(riscv_pcrel_relocs): Added comments.
(riscv_zero_pcrel_hi_reloc): Removed unused input_bfd.
(riscv_record_pcrel_hi_reloc): Updated.
(riscv_record_pcrel_lo_reloc): Likewise.
(riscv_resolve_pcrel_lo_relocs): Likewise. Check the original
type of auipc, to make sure the %pcrel_lo without any addends.
Otherwise, report dangerous relocation error.
(riscv_elf_relocate_section): Updated above functions are changed.
For R_RISCV_GOT_HI20, report dangerous relocation error when addend
isn't zero.
ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/pcrel-lo-addend-3a.d: New testcase.
* testsuite/ld-riscv-elf/pcrel-lo-addend-3a.s: Likewise.
* testsuite/ld-riscv-elf/pcrel-lo-addend-3b.d: New testcase.
Should report error since the %pcrel_lo with addend refers to
%got_pcrel_hi.
* testsuite/ld-riscv-elf/pcrel-lo-addend-3b.s: Likewise.
* testsuite/ld-riscv-elf/pcrel-lo-addend-3c.d: New testcase.
Should report error since the %got_pcrel_hi with addend.
* testsuite/ld-riscv-elf/pcrel-lo-addend-3c.s: Likewise.
* testsuite/ld-riscv-elf/pcrel-lo-addend-3.ld: Likewise.
|
|
I randomly hit a situation where gdbserver crashed immediately before
I issued a 'stepi' to GDB, it turns out that this causes GDB itself to
crash.
What happens is that as part of the stepi we try to insert some
breakpoints into the inferior, so from insert_breakpoints we figure
out what we want to insert, then, eventually, try to send some packets
to the remote to get the breakpoints inserted.
It is only at this point that GDB realises that the target has gone
away. This causes GDB to then enter this call stack:
unpush_and_perror
remote_unpush_target
generic_mourn_inferior
breakpoint_init_inferior
delete_breakpoint
update_global_location_list
So, we realise the target is gone and so delete the breakpoints
associated with that target.
GDB then throws a TARGET_CLOSE_ERROR from unpush_and_error.
This error is caught in insert_breakpoints where we then try to print
a nice error saying something like:
Cannot insert breakpoint %d: some error text here...
To fill in the '%d' we try to read properties of the breakpoint
object.
Which was deleted due to the delete_breakpoint call above.
And so GDB dies...
My proposal in this commit is that, should we catch a
TARGET_CLOSE_ERROR in insert_breakpoints, then we just rethrow the
error.
This will cause the main event loop to print something like:
Remote connection closed
Which I think is fine, I don't think the user will care much which
particular breakpoint GDB was operating on when the connection closed,
just knowing that the connection closed should be enough I think.
I initially added a test to 'gdb.server/server-kill.exp' for this
issue, however, my first attempt was not good enough, the test was
passing even without my fix.
Turns out that the server-kill.exp test actually kills the PID of the
inferior, not the PID of the server. This means that gdbserver is
actually able to send a packet to GDB saying that the inferior has
exited prior to gdbserver itself shutting down. This extra
information was enough to prevent the bug I was seeing manifest.
So, I have extended server-kill.exp to run all of the tests twice, the
first time we still kill the inferior. On the second run we hard kill
the gdbserver itself, this prevents the server from sending anything
to GDB before it exits.
My new test is only expected to fail in this second mode of
operation (killing gdbserver itself), and without my fix, that is what
I see.
gdb/ChangeLog:
* breakpoint.c (insert_bp_location): If we catch a
TARGET_CLOSE_ERROR just rethrow it, the breakpoints might have
been deleted.
gdb/testsuite/ChangeLog:
* gdb.server/server-kill.exp: Introduce global kill_pid_of, and
make use of this in prepare to select which pid we should kill.
Run all the tests twice with a different kill_pid_of value.
(prepare): Make use of kill_pid_of.
(test_stepi): New proc.
|
|
This commit provides a small performance improvement when starting up
CGEN based disassemblers by making use of __builtin_popcount.
The #if check used in this commit was copied from bfd/elf32-arm.c
where __builtin_popcount is also used.
I ran into this code while investigating some GDB tests that would
occasionally timeout. One of the reason these tests were having
problems is that the m16c and m32c disassemblers take so long to
initialise themselves. Speeding up count_decodable_bits helps, but is
not a total solution. Still, this felt like an easy win which added
minimal extra complexity, so I figure its worth doing.
opcodes/ChangeLog:
* cgen-dis.c (count_decodable_bits): Use __builtin_popcount when
available.
|
|
Commit 54758c3e398d made changes to the picojava support based on
https://sourceware.org/pipermail/binutils/2005-November/045136.html
An update from picojava to picojava II, I think. Unfortunately the
patch neglected any changes to the gas testsuite, resulting in
"FAIL: pj" since that date. This patch makes a few relatively simple
changes to cure the regression.
gas/
* config/tc-pj.c (md_apply_fix): Apply PJ_CODE_REL32 relocs.
* testsuite/gas/pj/ops.s: Update jsr, ret, getstatic,
putstatic, getfield, putfield, invokevirtual, invokespecial,
invokestatic, invokeinterface, goto_w, jsr_w assembly. Delete
version 1 picojava opcodes.
* testsuite/gas/pj/ops.d: Match expected output.
opcodes/
* pj-dis.c (print_insn_pj): Don't print trailing tab. Do
print separator for pcrel insns.
|
