v2 merges dwarf_decode_line_header_separate with
dwarf_decode_line_header and read_formatted_entries_separate with
read_formatted_entries in order to reduce code duplication.
gdb/debuginfod: Support on-demand debuginfo downloading
At the beginning of a session, gdb may attempt to download debuginfo
for all shared libraries associated with the process or core file
being debugged. This can be a waste of time and storage space when much
of the debuginfo ends up not being used during the session.
To reduce the gdb's startup latency and to download only the debuginfo
that is really needed, this patch adds on-demand, a.k.a lazy, downloading.
When 'set debuginfo enabled lazy' is on, gdb will attempt to download
a .gdb_index for each shared library instead of its full debuginfo.
Each debuginfo download will be deferred until gdb needs to expand symtabs
associated with the debuginfo's index.
Additionally, all separate debug objfiles are placed in objfiles_list
after their parent, instead of before. This ensures that any deferred
debuginfo downloaded during iteration over objfiles_list aren't skipped
by the loop. I also modified objfiles_safe so that it returns a safe
reverse iterator. Reverse iteration prevents iterator invalidation by
ensuring that separate debug objfiles are deleted before their parent objfile.
gdb: Buffer output during print_thread and print_frame_info
Introduce new ui_file buffer_file to temporarily collect output
during print_thread and print_frame_info. This ensures that
output from these functions is not interrupted by debuginfod
progress messages.
With the addition of deferred debuginfo downloading it is possible
for download progress messages to print during frame and thread
printing. Without any intervention we can end up with poorly
formatted output:
(gdb) backtrace
[...]
#8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (Downloading separate debug info for /lib64/libpython3.11.so.1.0
function_cache=0x561221b224d0, state=<optimized out>...
To fix this we accumulate the frame/thread output in a buffer_file
and have progress messages skip the buffer and print to gdb_stdout
immediately. This ensures progress messages print first, followed by
uninterrupted frame/thread info:
(gdb) backtrace
[...]
Downloading separate debug info for /lib64/libpython3.11.so.1.0
#8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (function_cache=0x561221b224d0, state=<optimized out>...
gdb: add 'lazy' setting for command 'set debuginfod enabled'
'set debuginfod enabled lazy' turns on debuginfod downloading like
'set debuginfod enabled on' but also enables ELF/DWARFs section
downloading via debuginfod_section_query.
If support for debuginfod section queries was not found at configure
time, 'set debuginfod enabled lazy' will print an error message
indicating the missing support and default to 'set debuginfod enabled on'.
Also update the help text and gdb.texinfo section for 'set debuginfod enabled'
with information on the lazy setting.
Add new function debuginfod_section_query. This function queries
debuginfod servers for an individual ELF/DWARF section associated with
a given build-id.
Also check for libdebuginfod version >= 0.188 at configure time.
debuginfod_section_query simply returns -ENOSYS if this condition
is not met.
clear_current_line overwrites the current line with chars_per_line
blank spaces. Printing the final space triggers a condition in
pager_file::puts that causes lines_printed to be incremented. If
lines_printed becomes greater than or equal to lines_allowed, the
pagination prompt will appear if enabled.
In this case the prompt is unnecessary since after printing the final
space clear_current_line immediately moves the cursor to the beginning
of the line with '\r'. A new line isn't actually started, so the prompt
ends up being spurious.
Additionally it's possible for gdb to crash during this pagination prompt.
Answering the prompt with 'q' throws an exception intended to bring gdb
back to the main event loop. But since commit 0fea10f32746,
clear_current_line may be called under the progress_update destructor.
The exception will try to propagate through the destructor, causing an abort.
To fix this, pagination is disabled for the duration for clear_current_line.
clear_current_line is also renamed to clear_progress_notify to help
indicate that it is a special purpose function intended for use with
do_progress_notify.
normally RELA relocs in BFD should not consider the contents of the
relocated place. The aarch64 psABI is even stricter, it specifies
(section 5.7.16) that all RELA relocs _must_ be idempotent.
Since the inception of the aarch64 BFD backend all the relocs have a
non-zero src_mask, and hence break this invariant. It's normally not
a very visible problem as one can see it only when the relocated place
already contains a non-zero value, which usually only happens sometimes
when using 'ld -r' (or as in the testcase when jumping through hoops to
generate the relocations). Or with alternative toolchains that do encode
stuff in the relocated places with the assumption that a relocation
to that place ignores whatever is there (as they can according to
the psABI).
Golang is such a toolchain and https://github.com/golang/go/issues/39927
is ultimately caused by this problem: the testcase testGCData failing
is caused by the garbage collection data-structure to describe a type
containing pointers to be wrong. It's wrong because a field that's
supposed to contain a file-relative offset (to some gcbits) has a
relocation applied and that relocation has an addend which also is
already part of the go-produced object file (so the addend is
implicitely applied twice).
bfd/
PR ld/30437
* elfnn-aarch64.c (elfNN_aarch64_howto_table): Clear src_mask
if all relocation descriptors.
ld/
* testsuite/ld-aarch64/rela-idempotent.s: New testcase.
* testsuite/ld-aarch64/rela-idempotent.d: New.
* testsuite/ld-aarch64/aarch64-elf.exp: Run it.
gdb/testsuite: change hardcoded assembly in gdb.arch/disp-step-insn-reloc.exp
When testing gdb.arch/disp-step-insn-reloc.exp with clang in an x86_64
machine, the compiled test case would segfault when returning from
the function can_relocate_call, with a suggestion of a broken stack.
The example assembly in the commment was the following:
f:
MOV $1, %[ok]
JMP end
set_point0:
CALL f ; tracepoint here.
end:
And the segmentation fault happening at the final "ret" instruction of
can_relocate_call. Looking at the disassembled version of the later
half of the important function, we see:
The epilogue of set_point0 (11cf for clang, 401146 for gcc) is the main
difference: GCC's version uses the leaveq instruction, which resets rsp
based on rbp, while clang adds the same constant to rsp that it
subtracted in the prologue. Clang fails because the return address that
is added by the "call f" instruction isn't accounted for.
This commit fixes that by adding a return instruction to f, which leaves
the rsp as the compilers would expect.
Approved-By: Andrew Burgess <email address hidden>
