Merging readline modifications #22
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit continues the work of the previous few commits. My goal is to expose the executable_changed observer through the Python API as an event. At this point adding executable_changed as an event to the Python API is trivial, but before I do that I would like to add some additional arguments to the observable, which currently has no arguments at all. The new arguments I wish to add are: 1. The program_space in which the executable was changed, and 2. A boolean flag that will indicate if the executable changed to a whole new path, or if GDB just spotted that the executable changed on disk (e.g. the user recompiled the executable). In this commit I change the signature of the observable and then pass the arguments through at the one place where this observable is notified. As there are (currently) no users of this observable nothing else needs updating. In the next commit I'll add a listener for this observable in the Python code, and expose this as an event in the Python API. Additionally, with this change, it should be possible to update the insight debugger to make use of this observable rather than using the deprecated_exec_file_display_hook (as it currently does), which will then allow this hook to be removed from GDB. There should be no user visible changes after this commit. Approved-By: Tom Tromey <[email protected]>
This commit makes the executable_changed observable available through the Python API as an event. There's nothing particularly interesting going on here, it just follows the same pattern as many of the other Python events we support. The new event registry is called events.executable_changed, and this emits an ExecutableChangedEvent object which has two attributes, a gdb.Progspace called 'progspace', this is the program space in which the executable changed, and a Boolean called 'reload', which is True if the same executable changed on disk and has been reloaded, or is False when a new executable has been loaded. One interesting thing did come up during testing though, you'll notice the test contains a setup_kfail call. During testing I observed that the executable_changed event would trigger twice when GDB restarted an inferior. However, the ExecutableChangedEvent object is identical for both calls, so the wrong information is never sent out, we just see one too many events. I tracked this down to how the reload_symbols function (symfile.c) takes care to also reload the executable, however, I've split fixing this into a separate commit, so see the next commit for details. Reviewed-By: Eli Zaretskii <[email protected]> Approved-By: Tom Tromey <[email protected]>
This commit fixes an issue that was discovered while writing the tests for the previous commit. I noticed that, when GDB restarts an inferior, the executable_changed event would trigger twice. The first notification would originate from: #0 exec_file_attach (filename=0x4046680 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513 #1 0x00000000006f3adb in reopen_exec_file () at ../../src/gdb/corefile.c:122 #2 0x0000000000e6a3f2 in generic_mourn_inferior () at ../../src/gdb/target.c:3682 #3 0x0000000000995121 in inf_child_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-child.c:192 #4 0x0000000000995cff in inf_ptrace_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-ptrace.c:125 #5 0x0000000000a32472 in linux_nat_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3609 #6 0x0000000000e68a40 in target_mourn_inferior (ptid=...) at ../../src/gdb/target.c:2761 #7 0x0000000000a323ec in linux_nat_target::kill (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3593 #8 0x0000000000e64d1c in target_kill () at ../../src/gdb/target.c:924 #9 0x00000000009a19bc in kill_if_already_running (from_tty=1) at ../../src/gdb/infcmd.c:328 #10 0x00000000009a1a6f in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:381 #11 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527 #12 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95 While the second originates from: #0 exec_file_attach (filename=0x3d7a1d0 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513 #1 0x0000000000dfe525 in reread_symbols (from_tty=1) at ../../src/gdb/symfile.c:2517 #2 0x00000000009a1a98 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:398 #3 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527 #4 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95 In the first case the call to exec_file_attach first passes through reopen_exec_file. The reopen_exec_file performs a modification time check on the executable file, and only calls exec_file_attach if the executable has changed on disk since it was last loaded. However, in the second case things work a little differently. In this case GDB is really trying to reread the debug symbol. As such, we iterate over the objfiles list, and for each of those we check the modification time, if the file on disk has changed then we reload the debug symbols from that file. However, there is an additional check, if the objfile has the same name as the executable then we will call exec_file_attach, but we do so without checking the cached modification time that indicates when the executable was last reloaded, as a result, we reload the executable twice. In this commit I propose that reread_symbols be changed to unconditionally call reopen_exec_file before performing the objfile iteration. This will ensure that, if the executable has changed, then the executable will be reloaded, however, if the executable has already been recently reloaded, we will not reload it for a second time. After handling the executable, GDB can then iterate over the objfiles list and reload them in the normal way. With this done I now see the executable reloaded only once when GDB restarts an inferior, which means I can remove the kfail that I added to the gdb.python/py-exec-file.exp test in the previous commit. Approved-By: Tom Tromey <[email protected]>
This patch adds a new, type-safe variant of gdb_bfd_openr_iovec. In this approach, the underlying user data is simply an object, the callbacks are methods, and the "open" function is a function view. Nothing uses this new code yet. Reviewed-By: Lancelot Six <[email protected]>
This changes the target_buffer constructor to initialize m_filename rather than assign to it. Reviewed-By: Lancelot Six <[email protected]>
This converts the mem_bfd_iovec / target_buffer code to use the new type-safe gdb_bfd_openr_iovec. Reviewed-By: Lancelot Six <[email protected]>
This converts the target fileio BFD iovec implementation to use the new type-safe gdb_bfd_openr_iovec. Reviewed-By: Lancelot Six <[email protected]>
This converts the minidebug BFD iovec implementation to the new type-safe gdb_bfd_openr_iovec. Reviewed-By: Lancelot Six <[email protected]>
This converts the solib-rocm BFD iovec implementations to the new type-safe gdb_bfd_openr_iovec. They were already essentially using this approach, just without the type-safe wrapper. Thanks to Lancelot Six for testing and fixing this patch. Co-Authored-By: Lancelot Six <[email protected]> Acked-by: Lancelot Six <[email protected]> Reviewed-By: Lancelot Six <[email protected]>
This removes the old gdb_bfd_openr_iovec entirely. I think any new code should use the type-safe approach. Reviewed-By: Lancelot Six <[email protected]>
PR29040 describes a FAIL for test-case gdb.threads/next-fork-other-thread.exp
and target board unix/-m32.
The FAIL happens due to the test executable running into an assert, which is
caused by a forked child segfaulting, like so:
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000 in ?? ()
...
I tried to reproduce the segfault with exec next-fork-other-thread-fork, using
TUI layout asm.
I set a breakpoint at fork and ran to the breakpoint, and somewhere during the
following session I ran into a gdb segfault here in
tui_find_disassembly_address:
...
/* Disassemble forward. */
next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
last_addr = asm_lines.back ().addr;
...
due to asm_lines being empty after the call to tui_disassemble, while
asm_lines.back () assumes that it's not empty.
I have not been able to reproduce that segfault in that original setting, I'm
not sure of the exact scenario (though looking back it probably involved
"set detach-on-fork off").
What likely happened is that I managed to reproduce PR29040, and TUI (attempted
to) display the disassembly for address 0, which led to the gdb segfault.
When gdb_print_insn encounters an insn it cannot print because it can't read
the memory, it throws a MEMORY_ERROR that is caught by tui_disassemble.
The specific bit that causes the gdb segfault is that if gdb_print_insn throws
a MEMORY_ERROR for the first insn in tui_disassemble, it returns an empty
asm_lines.
FWIW, I did manage to reproduce the gdb segfault as follows:
...
$ gdb -q \
-iex "set pagination off" \
/usr/bin/rustc \
-ex "set breakpoint pending on" \
-ex "b dl_main" \
-ex run \
-ex "up 4" \
-ex "layout asm" \
-ex "print \$pc"
...
<TUI>
...
$1 = (void (*)()) 0x1
(gdb)
...
Now press <up>, and the segfault triggers.
Fix the segfault by handling asm_lines.empty () results of tui_disassemble in
tui_find_disassembly_address.
I've written a unit test that exercises this scenario.
Tested on x86_64-linux.
Reviewed-by: Kevin Buettner <[email protected]>
PR tui/30823
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823
…ons. Updated show usage for MicroBlaze specific assembler options to include new entries. This patch has been tested for years of AMD Xilinx Yocto releases as part of the following patch set: https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils Signed-off-by: nagaraju <[email protected]> Signed-off-by: Neal Frager <[email protected]> --- V1->V2: - removed new options which were unnecessary - added documentation for MicroBlaze specific options Signed-off-by: Michael J. Eager <[email protected]>
I'm starting to work on these files, I thought it would be a good time to remove unused imports. These were identified by include-what-you-use. Tested by rebuilding. Change-Id: I3eaf3fa0ea3506c7ecfbc8ecff5031433b1dadb8 Reviewed-By: John Baldwin <[email protected]>
They are unused. Change-Id: I9b78837d41126ce1957aa1e8b08c82a422f06cbf Reviewed-By: John Baldwin <[email protected]>
At one time, circa 2006, there was a bug, which was presumably fixed
without adding a test case:
If you provided some relative path to the shared library, such as
with
export LD_LIBRARY_PATH=.
then gdb would fail to match the shared library name during the
TLS lookup.
I think there may have been a bit more to it than is provided by that
explanation, since the test also takes care to split the debug info
into a separate file.
In any case, this commit is based on one of Red Hat's really old
local patches. I've attempted to update it and remove a fair amount
of cruft, hopefully without losing any critical elements from the
test.
Testing on Fedora 38 (correctly) shows 1 unsupported test for
native-gdbserver and 5 PASSes for the native target as well as
native-extended-gdbserver.
In his review of v1 of this patch, Lancelot SIX observed that
'thread_local' could be used in place of '__thread' in the C source
files. But it only became available via the standard in C11, so I
used additional_flags=-std=c11 for compiling both the shared object
and the main program.
Also, while testing with CC_FOR_TARGET=clang, I found that
'additional_flags=-Wl,-soname=${binsharedbase}' caused clang
to complain that this linker flag was unused when compiling
the source file, so I moved this linker option to 'ldflags='.
My testing for this v2 patch shows the same results as with v1,
but I've done additional testing with CC_FOR_TARGET=clang as
well. The results are the same as when gcc is used.
Co-Authored-by: Jan Kratochvil <[email protected]>
Reviewed-By: Lancelot Six <[email protected]>
Acked-by: Tom de Vries <[email protected]>
* Changed the way how amiga eumlation is handlled to the new binutils way (maybe) * Fixed suggest explicit braces to avoid ambiguous ‘else’ * Default to static linking * Rework how PLT is handled * Enforce that the .rodata section is put its own read-only segment (program header) * Removed specific amigaos emulation, now it is based upon ppc32elf * Put. rodata section in its own segment just after the segment containing the .text section * Put .newlib_version section in another segment after the segment containing the .rodata section * .rodata in own segment with no overlap
PR 30906 * elf.c (_bfd_elf_slurp_version_tables): Test that the verref section header has been initialised before using it.
The PLT entry in executables and shared libraries contains an indirect branch, like jmp *foo@GOTPCREL(%rip) push $index_foo jmp .PLT0 or endbr64 jmp *foo@GOTPCREL(%rip) NOP padding which is used to branch to the function, foo, defined in another object. Each R_X86_64_JUMP_SLOT relocation has a corresponding PLT entry. The dynamic tags have been added to the x86-64 psABI to mark such PLT entries: https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6d824a52a42d173eb838b879616c1be5870b593e Add an x86-64 linker option, -z mark-plt, to mark PLT entries with #define DT_X86_64_PLT (DT_LOPROC + 0) #define DT_X86_64_PLTSZ (DT_LOPROC + 1) #define DT_X86_64_PLTENT (DT_LOPROC + 3) 1. DT_X86_64_PLT: The address of the procedure linkage table. 2. DT_X86_64_PLTSZ: The total size, in bytes, of the procedure linkage table. 3. DT_X86_64_PLTENT: The size, in bytes, of a procedure linkage table entry. and set the r_addend field of the R_X86_64_JUMP_SLOT relocation to the memory offset of the indirect branch instruction. The dynamic linker can use these tags to update the PLT section to direct branch. bfd/ * elf-linker-x86.h (elf_linker_x86_params): Add mark_plt. * elf64-x86-64.c (elf_x86_64_finish_dynamic_symbol): Set the r_addend of R_X86_64_JUMP_SLOT to the indirect branch offset in PLT entry for -z mark-plt. * elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Add DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT for -z mark-plt. (_bfd_x86_elf_finish_dynamic_sections): Set DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT. (_bfd_x86_elf_get_synthetic_symtab): Ignore addend for JUMP_SLOT relocation. (_bfd_x86_elf_link_setup_gnu_properties): Set plt_indirect_branch_offset. * elfxx-x86.h (elf_x86_plt_layout): Add plt_indirect_branch_offset. binutils/ * readelf.c (get_x86_64_dynamic_type): New function. (get_dynamic_type): Call get_x86_64_dynamic_type. include/ * elf/x86-64.h (DT_X86_64_PLT): New. (DT_X86_64_PLTSZ): Likewise. (DT_X86_64_PLTENT): Likewise. ld/ * ld.texi: Document -z mark-plt and -z nomark-plt. * emulparams/elf32_x86_64.sh: Source x86-64-plt.sh. * emulparams/elf_x86_64.sh: Likewise. * emulparams/x86-64-plt.sh: New file. * testsuite/ld-x86-64/mark-plt-1.s: Likewise. * testsuite/ld-x86-64/mark-plt-1a-x32.d: Likewise. * testsuite/ld-x86-64/mark-plt-1a.d: Likewise. * testsuite/ld-x86-64/mark-plt-1b-x32.d: Likewise. * testsuite/ld-x86-64/mark-plt-1b.d: Likewise. * testsuite/ld-x86-64/mark-plt-1c-x32.d: Likewise. * testsuite/ld-x86-64/mark-plt-1c.d: Likewise. * testsuite/ld-x86-64/mark-plt-1d-x32.d: Likewise. * testsuite/ld-x86-64/mark-plt-1d.d: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt tests.
Fixed the problem related to the fixup/relocations TLSTPREL. When the fixup is applied the addend is not added at the correct offset of the instruction. The offset is hard coded considering its big endian and it fails for Little endian. This patch allows support for both big & little-endian compilers. This patch has been tested for years of AMD Xilinx Yocto releases as part of the following patch set: https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils Signed-off-by: nagaraju <[email protected]> Signed-off-by: Neal Frager <[email protected]>
The range check should be checking for the range ffffffff80000000..7fffffff, not ffffffff70000000. This patch has been tested for years of AMD Xilinx Yocto releases as part of the following patch set: https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils Signed-off-by: nagaraju <[email protected]> Signed-off-by: Neal Frager <[email protected]> Signed-off-by: Michael J. Eager <[email protected]>
I ran across this site:
https://no-color.org/
... which lobbies for tools to recognize the NO_COLOR environment
variable and disable any terminal styling when it is seen.
This patch implements this for gdb.
Regression tested on x86-64 Fedora 38.
Co-Authored-By: Andrew Burgess <[email protected]>
Reviewed-by: Kevin Buettner <[email protected]>
Reviewed-By: Eli Zaretskii <[email protected]>
Approved-By: Andrew Burgess <[email protected]>
PR 30861 * config/tc-riscv.c (riscv_insert_uleb128_fixes): Release duplicated memory.
This backlink is not necessary, we always know the program space from the context. Pass it down the solib_unloaded observer. Change-Id: I45a503472dc791f517558b8141901472634e0556 Approved-By: Tom Tromey <[email protected]>
target_so_ops::free_so is responsible for freeing the specific lm_info object. All implementations basically just call delete. Remove that method, make the destructor of lm_info virtual, and call delete directly from the free_so function. Make the sub-classes final, just because it's good practice. Change-Id: Iee1fd4861c75034a9e41a656add8ed8dfd8964ee Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Now that the lm_info class hierarchy has a virtual destructor and therefore a vtable, use checked_static_cast instead of C-style cases to ensure (when building in dev mode) that we're casting to the right kind of lm_info. Change-Id: I9a99b7d6aa9a44edbe76377d57a7008cfb75a744 Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
A subsequent patch makes use of non-trivial types in struct so_list.
This trips on the fact that svr4_copy_library_list uses memcpy to copy
so_list objects:
so_list *newobj = new so_list;
memcpy (newobj, src, sizeof (struct so_list));
solib-svr4 maintains lists of so_list objects in its own internal data
structures. When requested to return a list of so_list objects (through
target_so_ops::current_sos), it duplicates the internal so_list lists,
using memcpy. When changing so_list to make it non-trivial, we would
need to replace this use of memcpy somehow. That would mean making
so_list copyable, with all the complexity that entails, just to satisfy
this internal usage of solib-svr4 (and solib-rocm, which does the same).
Change solib-svr4 to use its own data type for its internal lists. The
use of so_list is a bit overkill anyway, as most fields of so_list are
irrelevant for this internal use.
- Introduce svr4_so, which contains just an std::string for the name
and a unique_ptr for the lm_info.
- Change the internal so_list lists to be std::vector<svr4_so>. Vector
seems like a good choice for this, we don't need to insert/remove
elements in the middle of these internal lists.
- Remove svr4_free_library_list, free_solib_lists and ~svr4_info, as
everything is managed automatically now.
- Replace svr4_copy_library_list (which duplicated internal lists in
order to return them to the core) with so_list_from_svr4_sos, which
creates an so_list list from a vector of svr4_so.
- Generalize svr4_same a bit, because find_debug_base_for_solib now
needs to compare an so_list and an svr4_so to see if they are the
same.
Change-Id: I6012e48e07aace2a8172b74b389f9547ce777877
Approved-By: Pedro Alves <[email protected]>
Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Same rationale as the previous patch, but for solib-rocm. - Introduce rocm_so, which is a name a unique_name (see comment in rocm_update_solib_list for that) and a unique_ptr to the lm_info_svr4. - Change the internal lists from so_list lists to vectors of rocm_so. - Remove rocm_free_solib_list, as everything is automatic now. - Replace rocm_solib_copy_list with so_list_from_rocm_sos. Change-Id: I71e06e3ea22d6420c9e4e500501c06e9a13398a8 Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
I think this typedef hinders readability. First, it's not well named (it's not clear it contains lm_info_target objects). And hiding the fact that it contains unique pointers is not very useful either. I was looking at the code in solib_target_current_sos where the unique pointers get moved from the vector, and it wasn't obvious at all what the source of the move was. Change-Id: I4a5cda7c90554f018b7c466b1535b41d69cbcbe7 Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Make it a unique_ptr, so it gets automatically deleted when the so_list is deleted. Change-Id: Ib62d60ae2a80656239860b80e4359121c93da13d Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
... just because it seems to make sense to do so. Change-Id: Ie283c92d9b90c54e3deee96a43c6a942d8b5910b Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Remove this typedef. I think that hiding the real type (std::vector) behind a typedef just hinders readability. Change-Id: I80949da3392f60a2826c56c268e0ec6f503ad79f Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Make the field a vector directly, instead of a pointer to a vector. This was needed when so_list had to be a trivial type, which is not the case anymore. Change-Id: I79a8378ce0d0d1e2206ca08a273ebf332cb3ba14 Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Change the field from a `bfd *` to a gdb_bfd_ref_ptr to automatically manage the reference. Change-Id: I3ace18bea985bc194c5e67bb559eec567e258950 Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Change these two fields, simplifying memory management and copying. Change-Id: If2559284c515721e71e1ef56ada8b64667eebe55 Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Replace the hand-made linked list implementation with intrusive_list, simplying management of list items. Change-Id: I7f55fd88325bb197cc655c9be5a2ec966d8cc48d Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
I think this `so.clear ()` call is not useful. - so_list::clear deletes some things that now get automatically deleted when the so_list gets deleted right after in free_so. - so_list::clear resets some scalar fields of so_list, which we don't really care about since the so_list gets deleted right after. - so_list::clear calls target_so_ops::clear_so, of which there is a single implementation, svr4_clear_so. That implementation just resets a field in lm_info_svr4, which we don't care about, as it will get deleted when the so_list gets deleted right after. Change-Id: Ie4d72f2a04a4129e55c460bb5c69bc0af0d12b32 Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Remove this function, replace it with deleting the so_list in callers. Change-Id: Idbd0cb84674ade1d8e17af471550dbd388264f60 Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Now that so_list lists are implemented using intrusive_list, it doesn't really make sense for the element type to be named "_list". Rename to just `struct shobj` (`struct so` was deemed to be not greppable enough). Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e Approved-By: Pedro Alves <[email protected]> Reviewed-By: Reviewed-By: Lancelot Six <[email protected]>
Fixes:
CXX solib-target.o
/home/smarchi/src/binutils-gdb/gdb/solib-target.c:57:8: error: ‘lm_info_vector’ does not name a type
57 | static lm_info_vector
| ^~~~~~~~~~~~~~
/home/smarchi/src/binutils-gdb/gdb/solib-target.c: In function ‘intrusive_list<shobj> solib_target_current_sos()’:
/home/smarchi/src/binutils-gdb/gdb/solib-target.c:244:7: error: ‘solib_target_parse_libraries’ was not declared in this scope
244 | = solib_target_parse_libraries (library_document->data ());
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Ib477d3343b401017d79729118242143bc95f24b2
PR 30984 * ldelf.c (ldelf_place_orphan): Don't allow bfd_abs_section as a potential output section.
The recent change to record the DWARF language in the per-CU data yielded a race warning in my testing: ThreadSanitizer: data race ../../binutils-gdb/gdb/dwarf2/read.c:21779 in prepare_one_comp_unit This patch fixes the bug by applying the same style of fix that was done for the ordinary (gdb) language. I wonder if this code could be improved. Requiring an atomic for the language in particular seems unfortunate, as it is often consulted during index finalization. However, I haven't investigated this. Regression tested on x86-64 Fedora 38. Reviewed-by: Tom de Vries <[email protected]>
Fixed some forgotten bits
Added instruction for native build using clib4
Updated configure call
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.