| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The boolean expressions themselves are fine to use there.
|
|
Not the least due to its extremely rare use I didn't really like that
macro's introduction. Adjust swap_operand() accordingly instead.
|
|
The special property really only applies to the "extended" byte regs
having legacy word/dword counterparts.
While touching involved code also drop redundant byte checks from a
conditional in establish_rex(): The other remaining RegRex64 uses only
exist on registers which can't be used as register operands anyway.
Hence RegRex64 as an attribute of a (valid) register operand implies
that it's a byte reg.
|
|
While OBJ_MAYBE_ELF presently implies OBJ_ELF (due to obj-multi.h
including obj-elf.h for obscure reasons), there still need to be IS_ELF
checks to cover for the OBJ_MAYBE_ELF case. Note, however, that code
checking for ->debugging being true doesn't need such extra checks, as
the field can only ever be true when IS_ELF.
On the same basis reduce #ifdef-ary in debugging_pseudo().
Also move the field (into what on 64-bit architectures is a 32-bit gap)
and put it inside an OBJ_ELF conditional, too.
While there further switch int to bool in related code.
|
|
These ending directives are swallowed by buffer_and_nest() and hence
aren't seen by read_a_source_file(). Thus they also weren't announced to
the listing subsystem. That was, when macro expansions are included,
thus misguided to associate possible output resulting from the first
line of the construct being expanded with both the .endr and that first
line (i.e. showing it twice).
|
|
* gdb/breakpoint.c (watch_option_defs): Fix typo.
Copyright-paperwork-exempt: yes.
|
|
Relocations using 64-bit addends allow larger constant offset address
calculations to be fused.
|
|
|
|
When debugging ROCm code, you might have something like this:
__global__ void kernel ()
{
...
// break here
...
}
int main ()
{
// Code to call `kernel`
}
... where kernel is a function compiled to execute on the GPU. It does
not exist in the host x86-64 program that runs the main function, and
GDB doesn't know about that function until it is called, at which point
the runtime loads the corresponding code object and GDB learns about the
code of the "kernel" function. Before the GPU code object is loaded,
from the point of view of GDB, you might as well have blank lines
instead of the "kernel" function. The DWARF in the host program doesn't
describe anything at these lines.
So, a common problem that users face is:
- Start GDB with the host binary
- Place a breakpoint by line number at the "break here" line
- At this point, GDB only knows about the host code, the lines of the
`kernel` function are a big void.
- GDB finds no code mapped to the "break here" line and searches for
the first following line that has code mapped to it.
- GDB finds that the line with the opening bracket of the `main`
function (or around there) has code mapped to it, places breakpoint
there.
- User runs the program.
- The programs hits the breakpoint at the start of main.
- User is confused, because they didn't ask for a breakpoint in main.
If they continue, the code object eventually gets loaded, GDB reads the
debug info from it, re-evaluates the breakpoint locations, and at this
point the breakpoint is placed at the expected location.
The goal of this patch is to get rid of this annoyance.
A case similar to the one shown above can actually be simulated without
GPU-specific code: using a single source file to generate a library and
an executable loading that library (see the new test
gdb.linespec/line-breakpoint-outside-function.c for an example). Before
the library is loaded, trying to place a breakpoint in the library code
results in the breakpoint "drifting" down to the main function.
To address this problem, make it so that when a user requests a
breakpoint outside a function, GDB makes a pending breakpoint, rather
than placing a breakpoint at the next line with code, which happens to
be in the next function. When the GPU kernel or shared library gets
loaded, the breakpoint resolves to a location in the kernel or library.
Note that we still want breakpoints placed inside a function to
"drift" down to the next line with code. For example, here:
9
10 void foo()
11 {
12 int x;
13
14 x++;
There is probably no code associated to lines 10, 12 and 13, but the
user can still reasonably expect to be able to put a breakpoint there.
In my experience, GCC maps the function prologue to the line with the
opening curly bracket, so the user will be able to place a breakpoint
there anyway (line 11 in the example). But I don't really see a use
case to put a breakpoint above line 10 and expect to get a breakpoint in
foo. So I think that is a reasonable behavior change for GDB.
This is implemented using the following heuristic:
- If a breakpoint is requested at line L but there is no code mapped to
L, search for a following line with associated code (this already
exists today).
- However, if:
1. the found location falls in a function symbol's block
2. the found location's address is equal the entry PC of that
function
3. the found location's line is greater that the requested line
... then we don't place a breakpoint at the found location, we will
end up with a pending breakpoint.
Change the message "No line X in file..." to "No compiled code for line
X in file...". There is clearly a line 9 in the example above, so it
would be weird to say "No line 9 in file...". What we mean is that
there is no code associated to line 9.
All the regressions that I found this patch to cause were:
1. tests specifically this behavior where placing a breakpoint before
a function results in a breakpoint on that function, in which case I
removed the tests or changed them to expect a pending breakpoint
2. linespec tests expecting things like "break -line N garbage" to
error out because of the following garbage, but we now got a
different error because line N now doesn't resolve to something
anymore. For example, before:
(gdb) break -line 3 if foofoofoo == 1
No symbol "foofoofoo" in current context.
became
(gdb) break -line 3 if foofoofoo == 1
No line 3 in the current file.
These tests were modified to refer to a valid line with code, so
that we can still test what we intended to test.
Notes:
- The CUDA compiler "solves" this problem by adding dummy function
symbols between functions, that are never called. So when you try to
insert a breakpoint in the not-yet-loaded kernel, the breakpoint
still drifts, but is placed on some dummy symbol. For reasons that
would be too long to explain here, the ROCm compiler does not do
that, and it is not a desirable option.
- You can have constructs like this:
void host_function()
{
struct foo
{
static void __global__ kernel ()
{
// Place breakpoint here
}
};
// Host code that calls `kernel`
}
The heuristic won't work then, as the breakpoint will drift somewhere
inside the enclosing function, but won't be at the start of that
function. So a bogus breakpoint location will be created on the host
side. I don't think that people are going to use this kind of
construct often though, so we can probably ignore it (or at least it
shouldn't prevent making the more common case better).
ROCm doesn't support passing a lambda kernel function to
hipLaunchKernelGGL (the function used to launch kernels on the
device), but if it eventually does, there will be the same
problem.
I think that to properly support this, we will need some DWARF
improvements to be able to say "there is really nothing at these
lines" in the line table.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I3cc12cfa823dc7d8e24dd4d35bced8e8baf7f9b6
|
|
In commit:
commit 3055e3d2f13bb84db90b9c19d427c362053775d2
Date: Tue May 21 15:58:02 2024 +0100
gdb: add GDB side target_ops::fileio_stat implementation
I managed to place a NEWS entry in the wrong place. I put the entry
in 'Changes in GDB 15' rather than 'Changes since GDB 15'. This
commit moves the entry to the correct place.
|
|
This header file uses auto_obstack, found in gdbsupport/gdb_obstack.h.
This fixes an error shown when editing addrmap.h with clangd, and makes
it so addrmap.h includes what it uses.
Change-Id: I0b0c8d26638e2150fcb65c601098ed9df5a8945a
|
|
Remove some includes reported as unused by clangd.
Change-Id: Id1d5130430cdd2a37da1325a5eb67677f37905df
|
|
* dwarf.c (get_type_abbrev_from_form): Make uvalue param a
uint64_t. Localise variables. Don't bother clearing *data_return
and *addrev_num_return for a NULL return value.
|
|
In many cases the output of one run_cc_link_tests test is used as
input for another test. I hit a case where some system change caused
errors when compiling object files, but the old .so output from a
previous test run was still there, and then was used in following
tests.
* testsuite/lib/ld-lib.exp (run_ld_link_tests): Delete output
file before building.
(run_ld_link_exec_tests, run_cc_link_tests): Likewise.
|
|
PR 32093
* ctf-hash.c (ctf_dynhash_create_sized, ctf_hashtab_insert): Avoid
-Walloc-size warning.
|
|
On openSUSE Tumbleweed, I run into:
...
(gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls
continue^M
Continuing.^M
^M
Catchpoint 2 (call to syscall clone3), __clone3 () at clone3.S:62^M
(gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue
...
Fix this by updating another (see commit 8fbf220321d) regexp to also recognize
__clone3.
Tested on x86_64-linux.
|
|
Usually, with test-case gdb.arch/i386-disp-step-self-call.exp I get:
...
(gdb) x/1wx 0xffffc4f8^M
0xffffc4f8: 0x08048472^M
(gdb) PASS: $exp: check return address was updated correctly
...
but sometimes I run into:
...
(gdb) x/1wx 0xffffc5c8^M
0xffffc5c8: 0x0804917e^M
(gdb) FAIL: $exp: check return address was updated correctly
...
The problem is that here:
...
set next_insn_addr 0x[format %08X $next_insn_addr]
gdb_test "x/1wx 0x[format %x $sp]" "$hex:\\s+$next_insn_addr" \
"check return address was updated correctly"
...
we're trying to match string 0x0804917e against regexp 0x0804917E due to using
"%08X" as format string.
We only run into this problem if the address contains letters, which apparently
usually isn't the case.
Fix this by using "%08x" instead as format string.
Likewise in test-case gdb.arch/amd64-disp-step-self-call.exp.
Tested on x86_64-linux.
PR testsuite/32121
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32121
|
|
|
|
I noticed that process_enumeration_scope checks the result of
dwarf2_name. However, this isn't needed, because new_symbol does the
same check. This patch removes the unnecessary code.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
During the execution of the command: i686-w64-mingw32-dlltool
--input-def $def_filepath --output-delaylib $filepath --dllname qemu.exe
An error occurred:
i686-w64-mingw32-dlltool: failed to open temporary head file: ..._w64_mingw32_nativesdk_qemu_8_2_2_build_plugins_libqemu_plugin_api_a_h.s
Due to the path length exceeding the Linux system's file name length
limit (NAME_MAX=255), the temporary file name generated by the
i686-w64-mingw32-dlltool command becomes too long to open. To address
this, a new temporary file name prefix is generated using tmp_prefix =
prefix_encode ("d", getpid()), ensuring that the file name does not
exceed the system's length limit.
Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
Reviewed-by: Alan Modra <amodra@gmail.com>
|
|
Since R_386_TLS_DESC_CALL can only be used with
call *variable@TLSCALL(%eax)
and R_X86_64_TLSDESC_CALL can only be used with
call *variable@TLSCALL(%rax)
update TLS transition error report to display the expected register in
indirect CALL.
bfd/
PR ld/32017
* elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Initialize
the ax_register field.
(_bfd_x86_elf_link_report_tls_transition_error): Report the
expected register in elf_x86_tls_error_indirect_call error.
* elfxx-x86.h (elf_x86_link_hash_table): Add ax_register.
ld/
PR ld/32017
* testsuite/ld-i386/tlsgdesc2.d: Updated.
* testsuite/ld-i386/tlsgdesc2.s: Change jmp to call via ECX.
* testsuite/ld-x86-64/tlsdesc4.d: Updated.
* testsuite/ld-x86-64/tlsdesc4.s: Change jmp to call via RCX.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Force a PC-relative reference to .LC0 with:
__asm__ (".dc.a .LC0 - .");
for all targets.
Tested on x86, powerpc64le and aarch64.
* testsuite/discard_locals_relocatable_test.c: Force a PC-relative
reference to .LC0.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Since this test:
if (&no_such_symbol_ != NULL)
{
fprintf(stderr, "FAILED weak undef test 4: %s\n",
"&no_such_symbol_ is not NULL");
status = 1;
}
always fails when GOT is used and aarch64 always uses GOT, disable it
for aarch64 and PIC.
PR gold/32112
* testsuite/weak_undef_test.cc (main): Disable the
&no_such_symbol_ != NULL check for aarch64 and PIC.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Mostly whitespace fixes, some removal of excess parens.
|
|
Adjust the new test to pass on i686-pc-elf where it failed due to not
matching the _start address.
|
|
Since GCC 9 and older fail to compile PR gold/31830 tests:
$ gcc -S testsuite/ver_test_pr31830_b.c -o /tmp/x.s
testsuite/ver_test_pr31830_b.c:3:1: warning: ‘__symver__’ attribute directive ignored [-Wattributes]
void __collector_foo_2_2(void) {}
^~~~
use asm statement, instead of symver attribute, for GCC 9 and older.
PR gold/31830
* testsuite/ver_test_pr31830_b.c (__collector_foo_2_2): Use asm
statement, instead of symver attribute, for GCC 9 and older.
symver attribute with __asm__.
* testsuite/ver_test_pr31830_lto.c (__collector_foo_2_2): Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
When HAVE_STATIC and IFUNC_STATIC both are false, "make" reports:
Makefile:3796: warning: overriding recipe for target 'ifuncmain1picstatic'
Makefile:3788: warning: ignoring old recipe for target 'ifuncmain1picstatic'
Makefile:3900: warning: overriding recipe for target 'ifuncmain2picstatic'
Makefile:3892: warning: ignoring old recipe for target 'ifuncmain2picstatic'
Makefile:3932: warning: overriding recipe for target 'ifuncmain4picstatic'
Makefile:3924: warning: ignoring old recipe for target 'ifuncmain4picstatic'
Makefile:3972: warning: overriding recipe for target 'ifuncmain5picstatic'
Makefile:3964: warning: ignoring old recipe for target 'ifuncmain5picstatic'
Makefile:4048: warning: overriding recipe for target 'ifuncmain7picstatic'
Makefile:4040: warning: ignoring old recipe for target 'ifuncmain7picstatic'
due to duplicated rules for ifuncmain[12457]picstatic:
@GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
@HAVE_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
@IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
@IFUNC_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
@NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
@GCC_TRUE@@HAVE_STATIC_TRUE@@IFUNC_STATIC_TRUE@@IFUNC_TRUE@@NATIVE_LINKER_TRUE@ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld
Make rules for ifuncmain[12457]picstatic independent of HAVE_STATIC and
IFUNC_STATIC:
@GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
@IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
@NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES)
@GCC_TRUE@@IFUNC_TRUE@@NATIVE_LINKER_TRUE@ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld
PR gold/32116
* testsuite/Makefile.am (ifuncmain1picstatic): Make it independent
of HAVE_STATIC and IFUNC_STATIC.
(ifuncmain2picstatic): Likewise.
(ifuncmain4picstatic): Likewise.
(ifuncmain5picstatic): Likewise.
(ifuncmain7picstatic): Likewise.
* testsuite/Makefile.in: Regenerated.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Report invalid TLS operator, instead of relocation.
PR gas/28595
* config/tc-i386.c (gotrel): Replace int with unsigned int.
(i386_assemble): Report invalid TLS operator.
* testsuite/gas/i386/inval-tls.l: updated.
* testsuite/gas/i386/x86-64-inval-tls.l: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
The recent commit 089197010993b3a5dc50bf882470bab2de696d92 changed the
warnings when GDB reaches the end of the recorded history, and updated
tests to expect the new messages. The pattern used for
gdb.btrace/non-stop.exp, however, was too broad and could cause the
following test result:
...
(gdb) PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: prompt
^M
Reached end of recorded history; stopping.^M
Following forward execution will be added to history.^M
test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M
30 return arg; /* bp.2 */^M
^M
Reached end of recorded history; stopping.^M
Following forward execution will be added to history.^M
test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M
30 return arg; /* bp.2 */^M
PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 0
FAIL: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 1 (timeout)
...
This happens because the pattern looks like one of these 2:
"Reached end of recorded.*Backwards execution.*"
"Reached end of recorded.*Following forward.*"
What seems to have happened is that all the output came at once, and
most of it was consumed by the first '.*' pattern when checking for
thread 0, so there was no output left for checking thread 1. This commit
fixes that by making the expected outputs more exact.
I also fixed the whitespace errors in gdb_cont_to_no_history_backwards
that pre-dated the commit above, since I was already touching that proc.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
New 'no-delete-breakpoints' option for the 'runto' proc. This option
disables the delete_breakpoints call early on in this proc.
There are a couple of places in the testsuite where I have used:
proc no_delete_breakpoints {} {}
with_override delete_breakpoints no_delete_breakpoints {
if {![runto_main]} {
return
}
}
In order to avoid the deleting all breakpoints when I call
runto_main. I was about to add yet another instance of this pattern
and I figured that it's time to do this properly.
This commit adds the new option to 'runto' which causes the
delete_breakpoints call to be skipped.
And, we now forward any arguments from 'runto_main' through to
'runto', this means I can now just do:
if {![runto_main no-delete-breakpoints]} {
return
}
which I think is cleaner and easier to understand.
I've updated the two tests I found that use the old with_override
approach.
There should be no change in what is tested after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While reviewing a patch I wanted to understand which blocks existed at
a given address.
The 'maint print symbols' command does provide some of this
information, but that command displays all blocks within a given
symtab. If I want to know which blocks are at a given address I have
to figure that out for myself based on the output of 'maint print
symbols' ... and I'm too lazy for that!
So this command lists just those blocks at a given address, along with
information about the blocks type. This new command doesn't list the
symbols within each block, for that my expectation is that you'd cross
reference the output with that of 'maint print symbols'.
The new command format is:
maintenance info blocks
maintenance info blocks ADDRESS
This lists the blocks at ADDRESS, or at the current $pc if ADDRESS is
not given. Blocks are listed starting at the global block, then the
static block, and then the progressively narrower scoped blocks.
For each block we list the internal block pointer (which allows easy
cross referencing with 'maint print symbols'), the inferior address
range, along with other useful information.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
While reviewing a patch I wanted to view GDB's inline frame state. I
don't believe there's currently a maintenance command to view this
information, so in this commit I've added one.
The new command is:
maintenance info inline-frames
maintenance info inline-frames ADDRESS
The command lists the inline frames that start at ADDRESS, or at the
current $pc if no ADDRESS is given. The command also displays the
"outer" function in which the inline functions are present.
An example of the command output:
(gdb) maintenance info inline-frames
Cached inline state information for thread 1.
program counter = 0x401137
skipped frames = 1
bar
> foo
main
(gdb)
This tells us that function 'main' called 'foo' which called 'bar'.
The functions 'foo' and 'bar' are both inline and both start at the
address 0x401137. Currently GDB considers the inferior to be stopped
in frame 'foo' (note the '>' marker), this means that there is 1
skipped frame (function 'bar').
The function 'main' is the outer function. The outer function might
not start at 0x401137, it is simply the function that contains the
inline functions.
If the user does a 'step' then GDB will not actually move the inferior
forward, but will instead simply tell the user that the inferior
entered 'bar'. The output of 'maint info inline-frames' will change
like this:
(gdb) step
bar () at inline.c:6
6 ++global_counter;
(gdb) maintenance info inline-frames
Cached inline state information for thread 1.
program counter = 0x401137
skipped frames = 0
> bar
foo
main
(gdb)
Now GDB is in function 'bar' and there are no skipped frames.
I have renamed skipped_symbols to function symbols within the
inline_state class. We are now going to carry the "outer"
function (the function that contains all the inlined functions) within
this list (as the last entry), so the old name didn't really make
sense. As a consequence of this rename I've updated some comments.
I've changed stopped_by_user_bp_inline_frame to take a symbol rather
than a block. Previously we just used the block to access the
associated function symbol. After this commit we can just pass in the
function symbol directly, so lets do that.
New function gather_inline_frames contains some of the logic pulled
from skip_inline_frames. This new function builds the list of all
symbols of inlined functions that start at a given $pc value and also
the "outer" function that contains all of the inlined functions.
In skip_inline_frames I've split the loop logic into two. The loop to
build the function symbol list has moved to gather_inline_frames. The
loop to figure out how many of the inlined functions we are skipping
remains in skip_inline_frames and uses the result of calling
gather_inline_frames.
In inline_skipped_symbol there are some minor updates to the comment,
and I've tweaked one of the asserts now that the function symbols list
also contains the "outer" function (a <= becomes <).
The maintenance_info_inline_frames function is now and implements the
new maintenance command.
And _initialize_inline_frame is updated to register the new command.
I've added a basic test for the new command. Please excuse the file
name for the new test, in the next commit I'll be adding additional
tests and at that point the file name will make sense.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Make the inline_state::skipped_symbols a vector of 'const symbol *',
adding the const qualifier.
There's only a couple of places this leaks into the rest of GDB and in
both places its fine for the symbol to become const.
There should be no functional change after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This reverts commit 713e89012e43c83a6c1bb957c43ff58e5433336c.
Having inline_state::skipped_frames back will make a later patch in
this series easier.
|
|
|
|
Get TLS relocation name from its lex_got entry when reporting invalid
instructions with TLS relocations.
PR gas/28595
* config/tc-i386.c (gotrel): Moved from ...
(lex_got): There.
(i386_assemble): Get invalid TLS relocation name from its lex_got
entry when reporting TLS relocation error.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Since there is no TLS IE transition, allow R_386_TLS_LE_32 with KMOVD.
gas/
PR gas/28595
* config/tc-i386.c (i386_assemble): Remove BFD_RELOC_386_TLS_LE_32
from TLS code check.
* testsuite/gas/i386/inval-tls.s: Remove foo@tpoff(%eax).
* testsuite/gas/i386/inval-tls.l: Updated.
ld/
PR gas/28595
* testsuite/ld-i386/i386.exp: Run tlsle1.
* testsuite/ld-i386/tlsle1.d: New file.
* testsuite/ld-i386/tlsle1.s: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
In commit b5070480d74 ("[gdb/symtab] Change DWARF_ERROR from Dwarf Error to
DWARF Error") I changed the dwarf error prefix, but failed to update test-case
gdb.dwarf2/dw2-inter-cu-error.exp.
Fix this by updating the corresponding regexp in the test-case.
Tested on x86_64-linux.
|
|
I found a few more places where we can use GDB_PY_SET_HANDLE_EXCEPTION.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I found a few more places where we can use GDB_PY_HANDLE_EXCEPTION.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
It was suggested here [1] that the canonical prefix for dwarf errors
should not be "Dwarf Error: ", given that the canonical spelling is DWARF
instead of Dwarf.
Fix this by using "DWARF Error: " instead.
Given the use of DWARF_ERROR_PREFIX, that needs to be changed only in a single
location.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-August/211258.html
|
|
Result of:
...
$ sed -i 's/"Dwarf Error: /DWARF_ERROR_PREFIX\n"/' gdb/dwarf2/*
...
and manually fixing indentation.
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add a new header file gdb/dwarf2/error.h, containing macros:
- DWARF_ERROR, and
- DWARF_ERROR_PREFIX.
The DWARF_ERROR_PREFIX is to be used in dwarf errors in a follow-up patch.
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In gdb/dwarf2/read.c, I found a few strings "in module %s":
...
$ grep "in module %s" gdb/dwarf2/read.c | fgrep -v '['
"DIE at %s in module %s"),
error (_("Dwarf Error: Dummy CU at %s referenced in module %s"),
error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"),
error (_("Dwarf Error: DIE at %s referenced in module %s "
error (_("Dwarf Error: Dummy CU at %s referenced in module %s"),
error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"),
...
that are not using the commonly used "[in module %s]" notation. Fix these.
In one case, the string was also used in the middle rather than at the end of
the message, so fix that as well.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch supports Zcmp instruction 'cm.mva01s' and 'cm.mvsa01'.
All disassemble instructions use the sreg format.
Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
Co-Authored by: Simon Cook <simon.cook@embecosm.com>
Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
gas/ChangeLog:
PR 32036
* NEWS: Updated.
* config/tc-riscv.c (validate_riscv_insn): New operators.
(riscv_ip): Ditto.
* testsuite/gas/riscv/zcmp-mv.d: New test.
* testsuite/gas/riscv/zcmp-mv.s: New test.
include/ChangeLog:
PR 32036
* opcode/riscv-opc.h (MATCH_CM_MVA01S): New opcode.
(MASK_CM_MVA01S): New mask.
(MATCH_CM_MVSA01): New opcode.
(MASK_CM_MVSA01): New mask.
(DECLARE_INSN): New declarations.
* opcode/riscv.h (OP_MASK_SREG1): New mask.
(OP_SH_SREG1): New operand code.
(OP_MASK_SREG2): New mask.
(OP_SH_SREG2): New operand code.
(X_A0): New reg number.
(X_A1): Ditto.
(X_S7): Ditto.
(RISCV_SREG_0_7): New macro function.
opcodes/ChangeLog:
PR 32036
* riscv-dis.c (riscv_zcmp_get_sregno): New function.
(print_insn_args): New operators.
* riscv-opc.c (match_sreg1_not_eq_sreg2): New match function.
|
|
|
|
I disable gprofng until gprofng is ported to musl.
gprofng/ChangeLog
2024-08-22 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
PR gprofng/30779
PR gprofng/29593
PR gprofng/29477
* configure.ac: Disable gprofng build for *musl*.
* configure: Rebuild.
|
|
This patch changes ada_identical_enum_types_p to reuse the field names
that are computed earlier in the loop. This is a simple cleanup, but
also is useful for a larger change that I'm working on.
Tested on x86-64 Fedora 38.
|
|
If the CV_PTR_MODE_PMEM or CV_PTR_MODE_PMFUNC flags were set in an
LF_POINTER entry's attributes, there's a few extra bytes on the end that
we weren't accounting for.
Change handle_type so that we remap the containing_class field if it's
present, and add a test for this.
|
|
Currently, gdbserver hangs after stdin is closed while it tries to
write: "Remote side has terminated connection. GDBserver will reopen
the connection." This hang disappears if --once is also given. Since
the stdin connection won't ever reopen if it's closed, it's safe to
assume --once is desired.
The gdb.server/server-pipe.exp test was also updated to reflect this
change. There is now a second disconnect at the end of the proc,
with a tighter-than-normal timeout to catch if the command hangs as
it used to.
Co-Authored-By: Guinevere Larsen <blarsen@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29796
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
