Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update
the gdb/SECURITY.txt to be more explicit about some details. Specifically,
we now explicitly say that internal errors aren't security
vulnerabilities, and mention that users should review plugins before
running them, and under which conditions a plugin can cause a security
bug.
Reviewed-By: Tom Tromey <tom@tromey.com>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
I noticed commit 84786372e1 ("Fix size of register buffer") fixing a
stack-buffer-overflow found by AddressSanitizer in
amd64_windows_store_arg_in_reg:
...
- gdb_byte buf[8];
+ gdb_byte buf[16];
...
and wondered if we could have found this without AddressSanitizer.
I realized that the problem is that this:
...
gdb_byte buf[N];
...
regcache->cooked_write (regno, buf);
...
is using the deprecated variant of cooked_write instead of the one using
gdb::array_view:
...
/* Transfer of pseudo-registers. */
void cooked_write (int regnum, gdb::array_view<const gdb_byte> src);
/* Deprecated overload of the above. */
void cooked_write (int regnum, const gdb_byte *src);
...
and consequently cooked_write does not know the size of buf.
Fix this by using std::array, and likewise in other places in
gdb/amd64-windows-tdep.c.
In the process I fixed another out of bounds access here:
...
gdb_byte imm16[2];
...
cache->prev_sp = cur_sp
+ extract_unsigned_integer (imm16, 4, byte_order);
...
where we're reading 4 bytes from the 2-byte buffer imm16.
Tested by rebuilding on x86_64-linux.
Tested-By: Hannes Domani <ssbssa@yahoo.de>
We're doing such in fairly many places, and yet more are likely to
appear; centralize the logic, much like we already have
swap_2_operands().
While there also correct mis-indentation in adjacent code in
process_operands().
Without this APX support isn't really complete.
For Intel syntax displacement form is needed, such that symbolic
operands won't need prefixing by "offset". (The other form is actually
not used at all in Intel syntax.)
For the record: To restrict displacement form to Intel syntax is not
something I actually agree with.
We should not (silently) emit a REX prefix ahead of a REX2-encoded insn;
such encodings are illegal. Best we can do is fold the REX bits into the
REX2 prefix, and then zap the REX one from i.prefix[].
It can easily happen that the signal handler function
`handle_fatal_signal` uses various signal unsafe functions.
The problematic functions are `_` and `strsignal` which
can be pre-computed after the `setlocale` call is done.
Unfortunately when compiled with --disable-libbacktrace a
different code path is used, that calls the glibc function
`backtrace` which calls `malloc` and `free` and is therefore
also signal unsafe, that is probably unfixable, so there
is no attempt to fix anything in this code path.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713#c9
There are two useful ways to run a test-case, that are not represented by a
board file in gdb/testsuite/boards: check-read1 and check-readmore.
Consequently, they're not run either by make-check-all.sh.
Fix this by adding check-read1 and check-readmore to make-check-all.sh.
Tested on x86_64-linux. Verified with shellcheck.
Approved-By: Andrew Burgess <aburgess@redhat.com>
LLD has dropped the option -Ttext-segment for specifying image base
addresses, instead forcing the use of the --image-base option for both
ELF and PE targets. As it stands, GNU LD and LLVM LLD are incompatible,
having two different options for the same functionality.
This patch enables the use of --image-base on ELF targets, advancing
consistency and compatibility.
See: https://reviews.llvm.org/D70468https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#address-relatedhttps://sourceware.org/bugzilla/show_bug.cgi?id=25207
Moreover, a new test has been added to ensure -z separate-code behaviour
when used with -Ttext-segment stays the same. When this combination is
used, -Ttext-segment sets the address of the first segment (R), not the
text segment (RX), and like with -z noseparate-code, no segments lesser
than the specified address are created. If this behaviour was to change,
the first (R) segment of the ELF file would begin in a lesser address
than the specified text (RX) segment, breaking traditional use of this
option for specifying image base address.
When compiling dw2-multiple-debug-info.c using -gdwarf-5
-fdebug-types-section, we end with two .debug_info sections in the object
file:
...
$ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \
-gdwarf-5 \
-fdebug-types-section
$ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info
[10] .debug_info PROGBITS 0 000128 0000cd 00 GC 0 0 8
[12] .debug_info PROGBITS 0 0001f8 0000ad 00 C 0 0 8
...
One of them contains the CU for dw2-multiple-debug-info.c, the other contains
the TU for the type of variable a.
When trying to print the type of variable a, we get:
...
$ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a"
'a' has unknown type; cast it to its declared type
...
because the TU hasn't been read.
Fix this by adding support for reading multiple .debug_info sections, similar
to how that is done for multiple .debug_types sections, getting us instead:
...
$ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a"
type = class sp1::A {
...
}
...
Tested on x86_64-linux.
PR symtab/32223
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32223
Before this change resolve_dynamic_array_or_string was called for
all TYPE_CODE_ARRAY and TYPE_CODE_STRING types, but, in the end,
this function always called create_array_type_with_stride, which
creates a TYPE_CODE_ARRAY type.
Suppose we have
subroutine vla_array (arr1, arr2)
character (len=*):: arr1 (:)
character (len=5):: arr2 (:)
print *, arr1 ! break-here
print *, arr2
end subroutine vla_array
The "print arr1" and "print arr2" command at the "break-here" line
gives the following output:
(gdb) print arr1
$1 = <incomplete type>
(gdb) print arr2
$2 = ('abcde', 'abcde', 'abcde')
(gdb) ptype arr1
type = Type
End Type
(gdb) ptype arr2
type = character*5 (3)
Dwarf info using Intel® Fortran Compiler for such case contains following:
<1><fd>: Abbrev Number: 12 (DW_TAG_string_type)
<fe> DW_AT_name : (indirect string, offset: 0xd2): .str.ARR1
<102> DW_AT_string_length: 3 byte block: 97 23 8 (DW_OP_push_object_address; DW_OP_plus_uconst: 8)
After this change resolve_dynamic_array_or_string now calls
create_array_type_with_stride or create_string_type, so if the
incoming dynamic type is a TYPE_CODE_STRING then we'll get back a
TYPE_CODE_STRING type. Now gdb shows following:
(gdb) p arr1
$1 = ('abddefghij', 'abddefghij', 'abddefghij', 'abddefghij', 'abddefghij')
(gdb) p arr2
$2 = ('abcde', 'abcde', 'abcde')
(gdb) ptype arr1
type = character*10 (5)
(gdb) ptype arr2
type = character*5 (3)
In case of GFortran, compiler emits DW_TAG_structure_type for string type
arguments of the subroutine and it has only DW_AT_declaration tag. This
results in <incomplete type> in gdb. So, following issue is raised in gcc
bugzilla "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826".
Fixing above issue introduce regression in gdb.fortran/mixed-lang-stack.exp,
i.e. the test forces the language to C/C++ and print a Fortran string value.
The string value is a dynamic type with code TYPE_CODE_STRING.
Before this commit the dynamic type resolution would always convert this to
a TYPE_CODE_ARRAY of characters, which the C value printing could handle.
But now after this commit we get a TYPE_CODE_STRING, which
neither the C value printing, or the generic value printing code can
support. And so, I've added support for TYPE_CODE_STRING to the generic
value printing, all characters of strings are printed together till the
first null character.
Lastly, in gdb.opt/fortran-string.exp and gdb.fortran/string-types.exp
tests it expects type of character array in 'character (3)' format but now
after this change we get 'character*3', so tests are updated accordingly.
Approved-By: Tom Tromey <tom@tromey.com>
This really should be only an input; in particular it looks bogus that
O_add expressions are even altered. That altering and the recursion are
even pointless: Once expanding what the inner call would do (with
O_symbol) it becomes clear that this is no different than the default
case. Simplify the code accordingly, retaining the comment.
First of all make the declarations globally visible, such that producer
and consumer actually share them.
For the latter two simply add const (as PPC already had it,), while for
the former achieve the effect by converting to an array: There's no need
for the extra level of indirection.
When calling a function with double arguments, I get this asan error:
==7920==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0053131ece38 at pc 0x7ff79697a68f bp 0x0053131ec790 sp 0x0053131ebf40
READ of size 16 at 0x0053131ece38 thread T0
#0 0x7ff79697a68e in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long long), void const*, void const*, unsigned long long) C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:814
#1 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:845
#2 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:840
#3 0x7ff7927e237f in regcache::raw_write(int, gdb::array_view<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:874
#4 0x7ff7927e3c85 in regcache::cooked_write(int, gdb::array_view<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:914
#5 0x7ff7927e5d89 in regcache::cooked_write(int, unsigned char const*) C:/gdb/src/gdb.git/gdb/regcache.c:933
#6 0x7ff7911d5965 in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:216
Address 0x0053131ece38 is located in stack of thread T0 at offset 40 in frame
#0 0x7ff7911d565f in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:208
This frame has 4 object(s):
[32, 40) 'buf' (line 211) <== Memory access at offset 40 overflows this variable
It's because the first 4 double arguments are passed via XMM registers,
and they need a buffer of 16 bytes, even if we only use 8 bytes of them.
Approved-By: Tom Tromey <tom@tromey.com>
If amd64_windows_push_arguments is called with no arguments, then ARGS
can be NULL, and inside the passed-by-pointer block, memcpy is called
with this NULL, which is undefined behavior.
So this just disable the passed-by-pointer block if there are no
arguments.
Fixes the following ubsan error:
C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:244:12: runtime error: null pointer passed as argument 2, which is declared to never be null
Approved-By: Tom Tromey <tom@tromey.com>
clangd reports gdbsupport/common-gdbthread.h as unused in gdbthread.h,
which seems right, so remove it. Add it to two files that need it, but
were relying on the now-removed include.
Change-Id: I12916a044d0b15f346c4ad0e6527ce99a6d460e4
This commit adds recording support for the AVX instruction vzeroupper,
which zeroes the high bits of ymm registers 0..15. In the programmer's
manual, it is explicitly states that ymm registers 16..31 won't be
affected if present, so we only need to record the first 16 registers.
We record ymm_h registers since only the higher bits are touched, and
that reduces the memory footprint of the instruction.
This instruction is tested differently as we want to confirm we're only
saving the relevant registers, and we want to ensure we're saving
all of them, so it makes use of "maint print record-instruction" to see
exactly what was recorded.
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds support for the instructions VMOVDQU and VMOVDQA, used
to move values to/from 256 bit registers. Unfortunately, the
programmer's manual is very incomplete (if not wrong) about these
instructions, so the logic had to be reverse engineered from how gcc
actually encodes the instruction.
This commit also changes the memory regions from the test to store 256
bits, so its easier to test the instructions and that we're recording
ymm registers correctly.
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds recording support to all AVX and AVX2 instructions
of the form vpbroadcast. GDB is not yet concerned about AVX512 in
recording mode, so for now we only support the AVX2 registers and
instructions.
This commit also updates the gdb.reverse/i386-avx-reverse.exp to test
broadcast instructions.
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds support to recording instructions to unpack high
or low data from XMM registers, identified by the mnemonics in the
form: VPUNPCK [L|H] [BW|WD|DQ|QDQ].
All these instructions are encoded the exact same way, and only affect
the destination register, making them trivial to implement together.
It also updates the test gdb.reverse/i386-avx-reverse.exp to test these
new instructions. The test always uses ymm because the vpunpck
instructions overwrite the high bits, so we have to be able to record
the full ymm register, not just the output size.
Approved-By: Tom Tromey <tom@tromey.com>
This commit adds support to the x86_64 AVX instructions vmovd and vmovq.
The programmers manuals for Intel and AMD describe these 2 instructions
as being almost the same, but my local testing, using gcc 13.2 on Fedora
39, showed several differences and inconsistencies.
The instruction is supposed to always use the 3-byte VEX prefix, but I
could only find 2-byte versions. The instructions aren't differentiated
by the VEX.w bit, but by opcodes and VEX.pp.
This patch adds a test with many different uses for both vmovd and
vmovq. It also updates the test gdb.reverse/step-precsave.exp to
reference the generic "missing avx support" bug open in the bug tracker
(17346), instead of pointing to one that specifically calls out to
vmovd instructions.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23188
Approved-By: Tom Tromey <tom@tromey.com>
This patch introduces the information needed to properly identify the
VEX prefix, used to signal an AVX and AVX2 instruction, and introduces
a helper function to handle all AVX instruction, instead of adding to
the 3000 line long recording function.
This new function will temporarily set the current thread as "not
executing" so that it can read from pseudo registers as we record, since
most AVX/AVX2 instructions would benefit from recording ymm registers.
The new helper also handles unsupported instructions so that the largest
part of the i386_process_record doesn't have to be shifted by 2 spaces,
which made an unreadably big patch file.
The only expected difference to the end user added by this patch is a
small change to the unsupported message. This patch also updates the
test gdb.reverse/step-precsave.exp, by recognizing the new output.
As a note for the future, we don't handle xmm16-31 and ymm16-31 because
those require the EVEX prefix, meaning avx512 support.
Approved-By: Tom Tromey <tom@tromey.com>
In an effort to support AVX instructions when recording, we need to
allow replaying threads to access pseudo registers. Currently, if
we try to do that gdb will fail in a call to validate_registers_access,
because the thread is executing so GDB thinks it is unsafe to read
pseudo registers.
When replaying, the thread is really executing for all intents and
purposes, but the execution is just having GDB change values on
registers, so it will always be safe to read and write pseudo registers.
This commit changes functions that check for register access to allow
access when we are replaying. The check to whether we are replaying must
not happen when writing a core file, as record_full_list could be nullptr,
so we only check it if the thread is executing.
As of this commit, I don't know of a way to trigger this commit without
AVX support on record, so a test isn't provided. However, as soon as
record-full supports saving ymm registers, the AVX tests will test this
as well.
Approved-By: Tom Tromey <tom@tromey.com>
I saw a failure in gdb.debuginfod/build-id-no-debug-warning.exp which
I could only produce one time.
Normally the test output looks like this:
file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Downloading separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo...
(gdb) PASS: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no war
But one time I saw this:
file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Downloading 6.77 K separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo...
(gdb) FAIL: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no warnings
The difference is the "Downloading separate debug info for ..." line
has gained an extra '6.77 K' component. When I got the FAIL the
machine was under heavy load, so I suspect everything was running
pretty slow. I think the size is only added when the debuginfod
download is taking its time.
Anyway, the test in question is not expecting to see a size, which is
why it failed.
Every other debuginfod test does allow for an optional size being
printed, so lets update this test to also accept an optional size,
this should prevent failures like this in the future.
There are two test-cases that only run when the target board produces .dwp
files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp.
When running those test-cases with target board fission-dwp, I run into:
...
(gdb) ptype main^M
warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \
referenced by CU at offset 0xa6 [in module dwp-symlink]^M
type = <unknown return type> ()^M
(gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink
...
coming from:
...
# This case cannot work.
gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink"
...
I had a bit of difficulty understanding what the test-case does/tries to do,
so to build some understanding I reproduced the behaviour outside of the
test-case:
...
$ cat start.c
void _start (void) {}
$ gcc -gsplit-dwarf start.c -nostdlib
$ gdb -q -batch a.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ dwp -e a.out
$ rm start.dwo
$ gdb -q -batch a.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ ln -s a.out b.out
$ gdb -q -batch b.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ mv a.out.dwp b.out.dwp
$ gdb -q -batch b.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ gdb -q -batch a.out -ex "print _start"
During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \
referenced by CU at offset 0x0 [in module a.out]
warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \
referenced by CU at offset 0x0 [in module a.out]
$1 = {<text variable, no debug info>} 0x400144 <_start>
...
and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp,
and there's no way to find b.out.dwp starting from a.out.
The fact that a FAIL is produced is incorrect, gdb does nothing wrong.
Fix this by checking for the warning text instead.
While we're at it, fix this PATH as well:
...
(gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M
Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M
(gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \
/data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink
PATH: gdb.dwarf2/dwp-symlink.exp: cd \
/data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink
...
While we're at it, use string_to_regexp to simplify the test-case.
Tested on x86_64-linux, with target board fission-dwp.
After commit:
commit a1ccc78ea7
Date: Fri Oct 25 06:14:03 2024 +0200
[gdb/testsuite] Fix some test-cases for check-read1 (-lbl)
I notice that gdb.base/sect-cmd.exp would sometimes fail. The problem
is that by switching to line by line matching we now need to ensure
that the gdb_test_multiple patterns match up to the end of the line,
but don't actually include the trailing \r\n (yeah, our line by line
matching is weird). We need to be especially careful anywhere '.*' is
used as this can potentially match content on a subsequent line.
I have replaced '.*' with '\[^\r\n\]*(?=\r\n)', matching everything up
to the end of the line, but not the end of line itself, and I've made
use of '(?=\r\n)' in a couple of other places to ensure we match up to
the end of the line, but don't match the line terminator itself.
Creating a registry key using emplace calls new:
...
DATA *result = new DATA (std::forward<Args> (args)...);
...
which can throw a bad alloc, which will terminate gdb if called from a
destructor.
Fix this in a few places.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Say we simulate a bad alloc in exceptions_state_mc_init:
...
jmp_buf *
exceptions_state_mc_init ()
{
+ {
+ static bool throw_bad_alloc = true;
+ if (throw_bad_alloc)
+ {
+ throw_bad_alloc = false;
+
+ va_list dummy;
+ throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy));
+ }
+ }
catchers.emplace_front ();
return &catchers.front ().buf;
}
...
After starting gdb and typing "q", gdb terminates:
...
$ gdb -q
(gdb) terminate called after throwing an instance of 'gdb_quit_bad_alloc'
what(): std::bad_alloc
...
because the bad alloc (thrown in TRY_SJLJ) is caught by the noexcept on
gdb_rl_callback_read_char_wrapper_noexcept:
...
static struct gdb_exception
gdb_rl_callback_read_char_wrapper_noexcept () noexcept
{
struct gdb_exception gdb_expt;
/* C++ exceptions can't normally be thrown across readline (unless
it is built with -fexceptions, but it won't by default on many
ABIs). So we instead wrap the readline call with a sjlj-based
TRY/CATCH, and rethrow the GDB exception once back in GDB. */
TRY_SJLJ
...
Fix this by renaming gdb_rl_callback_read_char_wrapper_noexcept to
gdb_rl_callback_read_char_wrapper_sjlj and calling it from a wrapper function
that catches the bad alloc expection:
...
static struct gdb_exception
gdb_rl_callback_read_char_wrapper_noexcept () noexcept
{
try
{
return gdb_rl_callback_read_char_wrapper_sjlj ();
}
catch (gdb_exception &ex)
{
return std::move (ex);
}
}
...
getting us instead:
...
$ gdb -q
(gdb) bad alloc
(gdb) q
...
Tested on aarch64-linux.
Fix test-case gdb.cp/exceptprint.exp with make target check-read1 by limiting
the output of skip_libstdcxx_probe_tests_prompt by making the used command
more precise: using "info probes stap libstdcxx" instead of "info probes".
Tested on x86_64-linux.
Fix test-case gdb.threads/ia64-sigill.exp with make target check-read1 by
using a custom line-by-line exp_continue clause:
...
-re "\r\n\[^\r\n\]*(?=\r\n\[^\r\n\]*\r\n)" {
exp_continue
}
...
which drops a line each time it finds two lines in the buffer.
This allows the other clauses to use two-line patterns.
Tested on x86_64-linux.
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix some by using -lbl.
Tested on x86_64-linux.
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix some by using pipe / grep to filter out unnecessary output.
Tested on x86_64-linux.
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix some by using gdb_test_lines, as well as related gdb_get_lines.
Tested on x86_64-linux.
This adds some per-BFD locking to gdb_bfd_map_section and
gdb_bfd_get_full_section_contents.
It turned out that the background DWARF reader could race with the
auto-load code, because the reader might try to mmap a section when
the main thread was trying to read in .debug_gdb_scripts.
The current BFD threading model is that only BFD globals will be
locked, so any multi-threaded use of a BFD has to be handled specially
by the application.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31626
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
This changes auto-load.c ot use gdb_bfd_get_full_section_contents.
This shouldn't change any behavior, but makes it easier to add locking
in a subsequent patch.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
writevalue didn't handle 64-bit values, dropping the high 32 bits,
and also wrote any value in the range [0,15] as 0.
* tekhex.c (first_phase): Handle *ABS* symbols.
(writevalue): Rewrite.
