Commits on Source (15)
-
GDB Administrator authoredf4b228ee
-
Tom de Vries authored
In gdbserver_start, we have some code that determines what port number to use: ... # Port id -- either specified in baseboard file, or managed here. if [target_info exists gdb,socketport] { set portnum [target_info gdb,socketport] } else { # Bump the port number to avoid conflicts with hung ports. incr portnum } ... Factor this out into a new proc get_portnum. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
b6dfea24 -
Tom de Vries authored
When instrumenting get_portnum using: ... puts "PORTNUM: $res" ... and running: ... $ cd build/gdb $ make check TESTS=gdb.server/*.exp ... we get: ... Running gdb.server/target-exec-file.exp ... PORTNUM: 2345 Running gdb.server/stop-reply-no-thread-multi.exp ... PORTNUM: 2345 PORTNUM: 2346 PORTNUM: 2347 PORTNUM: 2348 PORTNUM: 2349 PORTNUM: 2350 ... So, while get_portnum does return increasing numbers in a single test-case, it restarts at each test-case. This is a regression since the introduction of persistent globals. Fix this by using "gdb_persistent_global portnum", such that we get: ... Running gdb.server/target-exec-file.exp ... PORTNUM: 2345 Running gdb.server/stop-reply-no-thread-multi.exp ... PORTNUM: 2346 PORTNUM: 2347 PORTNUM: 2348 PORTNUM: 2349 PORTNUM: 2350 PORTNUM: 2351 ... Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
c42c12f9 -
Tom de Vries authored
Factor out proc with_lock from with_rocm_gpu_lock, and move required procs lock_file_acquire and lock_file_release to lib/gdb-utils.exp. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
fbb0edfe -
Tom de Vries authored
In lib/rocm.exp we have: ... set gpu_lock_filename $objdir/gpu-parallel.lock ... This decides both the lock file name and directory. Factor out a new proc lock_dir that decides on the directory, leaving just: ... set gpu_lock_filename gpu-parallel.lock ... Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
007a7cb6 -
Tom de Vries authored
The lock directory returned by lock_dir is currently $objdir. It seems possible to leave a stale lock file that blocks progress in a following run. Fix this by using a directory that is guaranteed to be initially empty when using GDB_PARALLEL, like temp or cache. In gdb/testsuite/README I found: ... cache in particular is used to share data across invocations of runtest ... which seems appropriate, so let's use cache for this. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
a0a6e110 -
Tom de Vries authored
When instrumenting get_portnum using: ... puts "PORTNUM: $res" ... and running: ... $ cd build/gdb $ make check-parallel -j2 TESTS=gdb.server/*.exp ... we run into: ... Running gdb.server/abspath.exp ... PORTNUM: 2345 ... and: ... Running gdb.server/bkpt-other-inferior.exp ... PORTNUM: 2345 ... This is because the test-cases are run in independent runtest invocations. Fix this by handling the parallel case in get_portnum using: - a file $objdir/cache/portnum to keep the portnum variable, and - a file $objdir/cache/portnum.lock to serialize access to it. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
e82dca2a -
Tom de Vries authored
Make target check//% is the gdb variant of a similar gcc make target [1]. When running tests using check//%: ... $ cd build/gdb $ make check//unix/{-fPIE/-pie,-fno-PIE/-no-pie} -j2 TESTS=gdb.server/*.exp ... we get: ... $ cat build/gdb/testsuite.unix.-fPIE.-pie/cache/portnum 2427 $ cat build/gdb/testsuite.unix.-fno-PIE.-no-pie/cache/portnum 2423 ... The problem is that there are two portnum files used in parallel. Fix this by: - creating a common lockdir build/gdb/testsuite.lockdir for make target check//%, - passing this down to the runtests invocations using variable GDB_LOCK_DIR, and - using GDB_LOCK_DIR in lock_dir. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/31632 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31632 [1] https://gcc.gnu.org/install/test.html
c479e964 -
Alan Modra authored
* libbfd.c (bfd_mmap_local): Sanity check rsize against actual file offset and size, not an archive element offset and size.
c7a1fe22 -
Tom Tromey authored
dwarf2_per_objfile::adjust applies gdbarch_adjust_dwarf2_addr to an address, leaving the result unrelocated. However, this adjustment is only needed for text-section symbols -- it isn't needed for any sort of address mapping. Therefore, these calls can be removed from read_addrmap_from_aranges and create_addrmap_from_gdb_index. Approved-By: Andrew Burgess <aburgess@redhat.com>
91fc201e -
Tom Tromey authored
As with the previous patch, this patch removes some calls to dwarf2_per_objfile::adjust. These calls are not needed by the cooked indexer, as it does not create symbols or look up symbols by address. The call in dwarf2_ranges_read is similarly not needed, as it is only used to update an addrmap; and in any case I believe this particular call is only reached by the indexer.
a5a40101 -
Tom Tromey authored
read_call_site_scope does not need to call 'adjust', because in general the call site is not a symbol address, but rather just the address of some particular call.
6142f7cd -
Tom Tromey authored
Currently, read_attribute_value calls dwarf2_per_objfile::adjust on any address. This seems wrong, because the address may not even be in the text section. Luckily, this call is also not needed, because read_func_scope calls 'relocate', which does the same work.
12fddc10 -
Tom Tromey authored
All the calls to dwarf2_per_objfile::adjust have been removed, so we can remove this function entirely. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31261
b42d6854 -
Hannes Domani authored
If threads are disabled, either by --disable-threading explicitely, or by missing std::thread support, you get the following ASAN error when loading symbols: ==7310==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000002128 at pc 0x00000098794a bp 0x7ffe37e6af70 sp 0x7ffe37e6af68 READ of size 1 at 0x614000002128 thread T0 #0 0x987949 in index_cache_store_context::store() const ../../gdb/dwarf2/index-cache.c:163 #1 0x943467 in cooked_index_worker::write_to_cache(cooked_index const*, deferred_warnings*) const ../../gdb/dwarf2/cooked-index.c:601 #2 0x1705e39 in std::function<void ()>::operator()() const /gcc/9/include/c++/9.2.0/bits/std_function.h:690 #3 0x1705e39 in gdb::task_group::impl::~impl() ../../gdbsupport/task-group.cc:38 0x614000002128 is located 232 bytes inside of 408-byte region [0x614000002040,0x6140000021d8) freed by thread T0 here: #0 0x7fd75ccf8ea5 in operator delete(void*, unsigned long) ../../.././libsanitizer/asan/asan_new_delete.cc:177 #1 0x9462e5 in cooked_index::index_for_writing() ../../gdb/dwarf2/cooked-index.h:689 #2 0x9462e5 in operator() ../../gdb/dwarf2/cooked-index.c:657 #3 0x9462e5 in _M_invoke /gcc/9/include/c++/9.2.0/bits/std_function.h:300 It's happening because cooked_index_worker::wait always returns true in this case, which tells cooked_index::wait it can delete the m_state cooked_index_worker member, but cooked_index_worker::write_to_cache tries to access it immediately afterwards. Fixed by making cooked_index_worker::wait only return true if desired_state is CACHE_DONE, same as if threading was enabled, so m_state will not be prematurely deleted. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31694 Approved-By: Tom Tromey <tom@tromey.com>
5140d8e0