I noticed that isort runs for the manual stage:
...
$ pre-commit run --hook-stage manual
isort...............................................(no files to check)Skipped
...
That happens because unlike any other repo we're currently using, isort's
.pre-commit-hooks.yaml sets stages:
...
stages: [pre-commit, pre-merge-commit, pre-push, manual]
...
overriding the default setting in our .pre-commit-config.yaml:
...
default_stages: [pre-commit]
...
Fix this by adding a stages setting to the isort hook.
For C/C++/Fortran languages GDB prints same name variable multiple times in
case of variable shadowing and it is confusing for user to identify which
variable belongs to the current scope. So GDB now prints location information
for shadowed variables and add 'shadowed' field also in '-stack-list-locals'
and '-stack-list-variables' mi commands for super-block shadowed variable.
Suppose we have test.c file
1:int x = 3;
2: {
3: int x = 4;
4: int y = 5;
5: x = 99; /* break here */
6: }
The "-stack-list-locals" and "-stack-list-variables" mi commands at the
"break here" line gives the following output:
Before the change:
~~~
(gdb)
-stack-list-locals 0
^done,locals=[name="x",name="y",name="x"]
(gdb)
-stack-list-locals 1
^done,locals=[{name="x",value="4"},{name="y",value="5"},{name="x",value="3"}]
(gdb)
-stack-list-locals 2
^done,locals=[{name="x",type="int",value="4"},{name="y",type="int",value="5"},{name="x",type="int",value="3"}]
(gdb)
-stack-list-variables 0
^done,variables=[{name="x"},{name="y"},{name="x"}]
(gdb)
-stack-list-variables 1
^done,variables=[{name="x",value="4"},{name="y",value="5"},{name="x",value="3"}]
(gdb)
-stack-list-variables 2
^done,variables=[{name="x",type="int",value="4"},{name="y",type="int",value="5"},{name="x",type="int",value="3"}]
~~~
With this patch we obtain:
~~~
(gdb)
-stack-list-locals 0
^done,locals=[name="x",name="y",name="x"]
(gdb)
-stack-list-locals 1
^done,locals=[{name="x",value="4",filename="../test.c",fullname="/home/src/test.c",line="3"},{name="y",value="5"},{name="x",value="3",filename="../test.c",fullname="/home/src/test.c",line="1",shadowed="true"}]
(gdb)
-stack-list-locals 2
^done,locals=[{name="x",type="int",value="4",filename="../test.c",fullname="/home/src/test.c",line="3"},{name="y",type="int",value="5"},{name="x",type="int",value="3",filename="../test.c",fullname="/home/src/test.c",line="1",shadowed="true"}]
(gdb)
-stack-list-variables 0
^done,variables=[{name="x",filename="../test.c",fullname="/home/src/test.c",line="3"},{name="y"},{name="x",filename="../test.c",fullname="/home/src/test.c",line="1",shadowed="true"}]
(gdb)
-stack-list-variables 1
^done,variables=[{name="x",value="4",filename="../test.c",fullname="/home/src/test.c",line="3"},{name="y",value="5"},{name="x",value="3",filename="../test.c",fullname="/home/src/test.c",line="1",shadowed="true"}]
(gdb)
-stack-list-variables 2
^done,variables=[{name="x",type="int",value="4",filename="../test.c",fullname="/home/src/test.c",line="3"},{name="y",type="int",value="5"},{name="x",type="int",value="3",filename="../test.c",fullname="/home/src/test.c",line="1",shadowed="true"}]
~~~
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
For C/C++/Fortran/Ada languages GDB prints same name variable multiple
times in case of variable shadowing and it is confusing for user to identify
which variable belongs to the current scope. So for such cases add location
info to the innermost listed variables and for super block variables add
"shadowed" annotation in the form of "<file.c:line, shadowed>".
Suppose we have
1:int x = 3;
2: {
3: int x = 4;
4: int y = 52;
5: x = 99; /* break here */
6: }
Currently:
(gdb) info locals
x = 4
y = 52
x = 3
After applying this patch, we obtain:
(gdb) info locals
x = 4 <file.c:3>
y = 52
x = 3 <file.c:1, shadowed>
The patch adds the location annotations by keeping track of inner block
and already printed variables to identify shadowing. So, GDB now prints
"<file.c:line, shadowed>" for shadowed super-block variables and
"<file.c:line>" for innermost declarations of such variables only.
The location annotations are printed for shadowed variables in case of
C/C++/Fortran/Ada languages. In Rust, it is possible to declare a
variable with the same name many times. So in this case, just the first
instance of the variable is printed. RUST language test "var_reuse.exp"
fails with rustc compiler version >= 1.73 so XFAIL is added accordingly.
Fix regex expression in the gdb.opt/inline-locals.exp test according to
this change. The test update is only required due to the existing gdb
known ticket gdb/25695 where this issue is seen with 7.5.0 version on
sles15sp6 but it is not seen anymore on the newer gcc versions e.g.
gcc-11.4.0.
The symtab()/filename() nullptr check was added specifically to avoid
the crash seen in gdb.dwarf2/missing-type-name-for-templates.exp where
template symbols may have no associated source file.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
I noticed that the get_selected_block argument is mostly 0, NULL, or nullptr.
Make nullptr the default argument.
Approved-By: Tom Tromey <tom@tromey.com>
I don't know why -- though I suspect there may have been a change to
the output of "gnatmake --version" -- but recently some gdb.ada tests
have stopped running when llvm-gnatmake is used.
The llvm-gnatmake I am testing against prints a version string that
isn't recognized by gnat_version_compare. However, it seems to me
that AdaCore is probably the main place where this can even occur; and
furthermore that without some extra work, it seems reasonable for
gnat_version_compare to assume that an unrecognized gnatmake is "very
new".
The test case gdb.ada/mi_var_access.exp was failing with gnat-llvm.
Debugging this, I found that the problem was that with gnat-llvm, the
array descriptor would have a NULL pointer for the bounds when the
array was invalidated. That is, examining the object in C mode:
(gdb) p a_string_access
$1 = {
P_ARRAY = 0x0,
P_BOUNDS = 0x0
}
whereas when using GNAT we see:
(gdb) print a_string_access
$1 = {
P_ARRAY = 0x0,
P_BOUNDS = 0x402750
}
This was causing ada_type_of_array to return nullptr; with that
bubbling up to varobj and then MI as a "wrong" type in the MI output.
It seems to me that a null P_BOUNDS is reasonable; and that this case
can be handled in ada_type_of_array by examining the type of P_BOUNDS
without needing the bounds themselves.
The bound values are both set to 0 in this case, because
experimentally this is what is done at runtime in the GNAT-generated
code. Perhaps an explicitly empty array (1/0) would be better; I am
not certain.
I came across some code in buildsym_compunit::make_blockvector that uses
hardcoded constants 0 and 1:
...
gdb_assert (blockvector->block (0)->is_global_block ());
gdb_assert (blockvector->block (1)->is_static_block ());
...
Fix this by instead using the symbolic constants GLOBAL_BLOCK and
STATIC_BLOCK.
The same function has an odd-looking for loop that uses a hard-coded '1' to
skip the global block:
...
/* The 'J > 1' here is so that we don't place the global block into
the map. For CU with gaps, the static block will reflect the
gaps, while the global block will just reflect the full extent of
the range. */
for (int j = num_blocks; j > 1; )
{
--j;
struct block *b = blockvector->block (j);
...
Fix this by rewriting it into an ordinary descending for loop, and using
symbolic constant GLOBAL_BLOCK to avoid the global block:
...
for (int j = num_blocks - 1; j > GLOBAL_BLOCK; --j)
{
struct block *b = blockvector->block (j);
...
Approved-By: Tom Tromey <tom@tromey.com>
PE/COFF stores symbol section numbers in a 16-bit field. Binutils used
signed 16-bit handling there, which limited normal PE objects to 32767
sections even though MSVC and Clang already accept a larger unsigned
range.
Raise the normal PE section limit to 65279, while keeping the PE/COFF
special section-number values for undefined, absolute and debug symbols
working correctly. Do this by decoding and encoding normal PE symbol
section numbers as unsigned values in the ordinary range, but preserving
the reserved PE constants explicitly.
Also add a gas test that exercises a normal PE object above the old
32767-section limit and checks that objdump reports the high section
number correctly.
bfd/ChangeLog:
* coffcode.h (COFF_DEFAULT_MAX_NSCNS): Define.
(bfd_coff_std_swap_table): Use it for the default maximum section
count.
(ticoff0_swap_table): Likewise.
(ticoff1_swap_table): Likewise.
* peXXigen.c (pe_decode_sym_section_number): New function.
(pe_encode_sym_section_number): New function.
(_bfd_XXi_swap_sym_in): Use pe_decode_sym_section_number.
(_bfd_XXi_swap_sym_out): Use pe_encode_sym_section_number.
include/ChangeLog:
* coff/pe.h (IMAGE_SYM_UNDEFINED): Define.
(IMAGE_SYM_ABSOLUTE): Define.
(IMAGE_SYM_DEBUG): Define.
(IMAGE_SYM_SECTION_MAX): Define.
gas/ChangeLog:
* testsuite/gas/pe/pe.exp: Run large-obj-normal.
* testsuite/gas/pe/large-obj-normal.s: New test.
* testsuite/gas/pe/large-obj-normal.d: New test.
Signed-off-by: Oleg Tolmatcev <oleg.tolmatcev@gmail.com>
A recent commit added this top-level setting to .pre-commit-config.yaml:
...
files: '^(gdb|gdbserver|gdbsupport)/'
...
This broke the codespell-log hook, which is a commit-msg hook, which is called
with the commit message as first argument, typically .git/COMMIT_EDITMSG.
However, the top-level files setting filters out .git/COMMIT_EDITMSG, with the
consequence that the commit-msg hook is no longer called.
It seems obvious to me that this is a pre-commit bug: the files field is there
to filter files in the repository, which .git/COMMIT_EDITMSG is not one of.
But upstream disagrees [1].
The fix suggested upstream is to include .git/COMMIT_EDITMSG in the default
files setting.
That indeed works for a regular commit, but not for something like this:
...
$ tmp=$(mktemp)
$ echo 'msg' > $tmp
$ pre-commit run --hook-stage commit-msg --commit-msg-filename $tmp
...
which is roughly what we're using in the regression test.
We can't use .git/COMMIT_EDITMSG in the regression test, because the user may
be editing it, or using it in some other way.
We also cannot use say gdb/testsuite/gdb.src/commit-msg.txt, because using
that filename doesn't detect the regression.
[1] https://github.com/pre-commit/pre-commit/issues/3720
It's not clear why these were covered; it has been like this from the very
beginning of (available) source history. Yet more oddly, an old ia64
testcase actually uses such malformed escape sequences (which are being
adjusted).
The handling there is broken in several ways:
- It gets in the way of macro parameter names starting with one of the not
special cased values.
- For perhaps a small set of targets (SINGLE_QUOTE_STRINGS, M68k MRI
mode): While the "quotechar" static variable allows for string quotation
by other than '"', the case labels circumventing the warning only (and
potentially wrongly) cover '"'.
read.c:next_char_of_string() having similar checking in place, drop the
special casing (as as_warn() invocation) from here.
While adjusting macros/macros.exp XFAIL-ary for an affected testcase,
correct the referenced manifest symbol at the same time.
Besides needlessly consuming space (it's not that much, but still), the
unnecessary duplication also means the need to edit things in two places
when changes are being made.
Reportedly (e.g. [1]) the LOCK handling is special to %cr0 / %cr8 only.
Deal with it this way also in assembler and disassembler.
For the assembler also introduce a separate feature indicator: Not all
64-bit CPUs support this insn form; only most AMD (and presumably all
Hygon) ones do. Register names %cr9 ... %cr15 thus become invalid outside
of 64-bit mode altogether (unprefixed forms become ordinary symbol names),
while %cr8's availability outside of 64-bit mode now depends on the new
feature indicator.
For the disassembler don't limit this handling to non-64-bit modes. Use
of LOCK is similarly permitted in 64-bit mode. Instead don't handle LOCK
this way when "intel64" was specified as an option.
[1] https://lists.xen.org/archives/html/xen-devel/2026-07/msg00391.html
gas/config/tc-loongarch.c: In function ‘md_apply_fix’:
gas/config/tc-loongarch.c:1886:7: error: a label can only be part of a statement and a declaration is not a statement
unsigned int subtype;
^
* config/tc-loongarch.c (md_apply_fix <BFD_RELOC_LARCH_CFA>):
Avoid gcc-4.9 error.
The recent ptid work came from a bug where a problem was observed due
to sign extension. That bug also suggested documenting the guaranteed
range of thread- and process-ids in the remote protocol.
This patch documents these as being 32-bit values at minimum. I also
added static asserts to ensure this is true -- note that although
'int' may be 16 bit per the C standard, I doubt gdb would build on
such a host.
I didn't specify a maximum because it is host-dependent. This is
perhaps something to change, and while I do have some work in this
area, it's quite invasive. Also, while widening the range here would
be good, it would also be incompatible in a sense, where a newer
protocol implementation may end up using values not supported by older
versions of gdb. Perhaps one idea would be to simply change these
both to int32_t and move on.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33979
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Commit 8bf4b69718 ("LoongArch: Fix relaxation alignment with ld -r (PR
33236)") has broken the kernel modules on Debian sid. The expectation
of the kernel is all the source files which would be linked into a
module are compiled with -mno-relax so the module should not contain
R_LARCH_ALIGN, thus the module loader rejects any module containing
R_LARCH_ALIGN.
To restore the correctness of the expectation, only insert the align
section if an input has R_LARCH_ALIGN or R_LARCH_ALIGN (i.e. bytes may
be removed from that input). Regardless of the kernel modules, it also
does not make too much sense to bloat the output with NOPs and
R_LARCH_ALIGN if no input ever contains R_LARCH_ALIGN and R_LARCH_ALIGN
anyway.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
init_static_types_internal() walks the CTF type section that comes
directly from an object file's .ctf section. During the first counting
pass it treats a CTF_K_FORWARD record's ctt_type as the CTF_K_* kind of
the forwarded tag and bumps the corresponding population count:
if (kind == CTF_K_FORWARD)
pop[tp->ctt_type]++;
pop[] is a fixed-size stack array with CTF_K_MAX + 1 (64) entries, but
ctt_type is a 32-bit value read straight from the file and is never
validated. A crafted dict whose forward record carries a ctt_type
greater than CTF_K_MAX therefore causes an out-of-bounds write to the
stack at an attacker-controlled index.
The type walk is reachable from ctf_bufopen()/ctf_open(), i.e. whenever
libctf opens a dict: ld while linking CTF, and objdump/nm --ctf. The
second pass already tolerates an out-of-range ctt_type (ctf_name_table()
has a default case), so only this first-pass index was unguarded.
Reject a ctt_type outside the valid kind range as ECTF_CORRUPT, matching
the existing corruption handling in the same loop.
Reproduced with a 65-byte in-memory dict (one CTF_K_FORWARD record whose
ctt_type is 64) passed to ctf_bufopen(). Before the fix, AddressSanitizer
reports a stack-buffer-overflow at ctf-open.c:759 overflowing pop[64];
after the fix ctf_bufopen() returns ECTF_CORRUPT. Valid forwards
(ctt_type of CTF_K_STRUCT/UNION/ENUM) and the boundary value CTF_K_MAX
still open successfully.
Signed-off-by: Naveed Khan <naveed@digiscrypt.com>
This fixes the error reported when compiling with GCC 4.9:
opcodes/aarch64-opc-2.c:29:3: error: initializer element is not constant
{AARCH64_OPND_CLASS_INT_REG, "Rd", OPD_F_HAS_INSERTER | OPD_F_HAS_EXTRACTOR, {AARCH64_FIELD (0, 5)}, "an integer register"},
^
opcodes/aarch64-opc-2.c:29:3: error: (near initialization for ‘aarch64_operands[1].fields[0]’)
gcc-4.9 doesn't like an empty initialiser.
binutils/readelf.c: In function ‘process_relocs’:
binutils/readelf.c:10229:5: error: missing initializer for field ‘sh_name’ of ‘Elf_Internal_Shdr’ [-Werror=missing-field-initializers]
Elf_Internal_Shdr section = {};
* readelf.c (process_relocs): Avoid gcc-4.9 compile error.
Consider test.c, compiled to a.out using "g++ -g test.c":
...
1 namespace mod_a { int xxx = 10; }
2 namespace mod_b { using namespace mod_a;
3 int yyy = 20; }
4 int main (void) {
5 using namespace mod_b;
6 void (xxx + yyy);
7 return 0;
8 }
...
When trying to print the value of variable xxx we get:
...
$ gdb -q -batch a.out -ex start -ex "print xxx"
...
Temporary breakpoint 1, main () at test.c:7
7 return 0;
No symbol "xxx" in current context.
...
The symbol xxx is defined in namespace mod_a, so it's available as:
...
(gdb) p mod_a::xxx
$1 = 10
...
and namespace mod_b uses namespace mod_a, so it's available as:
...
(gdb) p mod_b::xxx
$2 = 10
...
Then main uses namespace mod_b so xxx should also be available in main, but
it's not.
The problem happens here in cp_lookup_symbol_via_imports:
...
Thread 1 "gdb" hit Breakpoint 1, cp_lookup_symbol_via_imports (scope=0x5f43d0 "",
name=0xfffffffface0 "xxx", block=0x2fba5a0, domain=..., search_scope_first=0,
declaration_only=0, search_parents=1, found_symbols=...)
at /home/vries/gdb/src/gdb/cp-namespace.c:505
505 cp_lookup_symbol_via_imports (current->import_src, name,
...
We're about to follow the "using namespace mod_b" statement:
...
(gdb) p *current
$1 = {import_src = 0x2ed2140 "mod_b", import_dest = 0x66e910 "", alias = 0x0,
declaration = 0x0, next = 0x0, decl_line = 5, searched = 1,
excludes = {0x0}}
...
But it does so using the current block, which is the function block for main:
...
(gdb) p block->function ().m_name
$7 = 0x2f8bc20 "main()"
...
and the block containing the "using namespace mod_a" statement is the static
block.
Fix this by additionally iterating over the static and global blocks instead
of only using the current block.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34034
Consider test.c, compiled to a.out using "g++ -g test.c":
...
1 namespace mod_a { int xxx = 10; }
2 namespace mod_b { using namespace mod_a;
3 int yyy = 20; }
4 int main (void) {
5 using namespace mod_b;
6 void (xxx + yyy);
7 return 0;
8 }
...
When trying to print the value of non-existent variable mod_a::yyy, we get:
...
$ gdb -q -batch a.out -ex start -ex "print mod_a::yyy"
...
Temporary breakpoint 1, main () at test.c:7
7 return 0;
$1 = 20
...
The problem is in cp_lookup_symbol_via_imports, where we decide that the
"using namespace mod_b" from main is applicable in scope mod_a.
More concretely, cp_lookup_symbol_via_imports is called with:
- scope == "mod_a",
- name == "yyy", and
- block.m_function.m_name == "main()",
and when looking at "using namespace mod_b":
...
(gdb) p *current
$12 = {import_src = 0x344018c "mod_b", import_dest = 0x1b477a0 "",
alias = 0x0, declaration = 0x0, next = 0x0, decl_line = 5,
searched = 0, excludes = {0x0}}
...
we hit "directive_match = true" because strlen (current->import_dest) == 0.
Fix this by being more strict in the calculation of directive_match:
...
if (len == 0)
- directive_match = true;
+ {
+ const char *current_scope = (block->function_block () != nullptr
+ ? block->scope ()
+ : nullptr /* Don't know. */);
+ directive_match = (current_scope != nullptr
+ ? streq (scope, current_scope)
+ : true /* Assume there's a match. */);
+ }
...
which gets us:
- current_scope == "", and
- directive_match == false,
because scope == "mod_a", so streq (scope, current_scope) == false.
As is clear from the code, in case we don't know the current scope, we assume
there's a match. This may be harmless, or this may describe a cornercase we
haven't run into yet. If so, it's a pre-existing issue.
The new test-case contains regression tests for:
- PR34051, and
- PR34034 for which it contains a kfail.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34051
In cp_lookup_symbol_via_imports, we have a complex assignment:
...
directive_match = (search_parents
? (startswith (scope, current->import_dest)
&& (len == 0
|| scope[len] == ':'
|| scope[len] == '\0'))
: streq (scope, current->import_dest));
...
Writing it like this makes it:
- harder to comment on parts of the expression, and also
- harder to understand and modify it.
Also, len == 0 makes the startswith redundant, so that part of the expression
can be hoisted. Doing so makes it clear that scope is not compared against in
all cases.
Fix this by breaking this up into three separate assignments:
...
if (search_parents)
{
if (len == 0)
directive_match = true;
else
directive_match = (startswith (scope, current->import_dest)
&& (scope[len] == ':'
|| scope[len] == '\0'));
}
else
directive_match = streq (scope, current->import_dest);
...
Approved-By: Tom Tromey <tom@tromey.com>
The -O option was added to x86 assembler by
commit b6f8c7c452
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Feb 27 07:36:33 2018 -0800
x86: Add -O[2|s] assembler command-line options
On x86, some instructions have alternate shorter encodings:
1. When the upper 32 bits of destination registers of
andq $imm31, %r64
testq $imm31, %r64
xorq %r64, %r64
subq %r64, %r64
known to be zero, we can encode them without the REX_W bit:
andl $imm31, %r32
testl $imm31, %r32
xorl %r32, %r32
subl %r32, %r32
This optimization is enabled with -O, -O2 and -Os.
2. Since 0xb0 mov with 32-bit destination registers zero-extends 32-bit
immediate to 64-bit destination register, we can use it to encode 64-bit
mov with 32-bit immediates. This optimization is enabled with -O, -O2
and -Os.
3. Since the upper bits of destination registers of VEX128 and EVEX128
instructions are extended to zero, if all bits of destination registers
of AVX256 or AVX512 instructions are zero, we can use VEX128 or EVEX128
encoding to encode AVX256 or AVX512 instructions. When 2 source
registers are identical, AVX256 and AVX512 andn and xor instructions:
VOP %reg, %reg, %dest_reg
can be encoded with
VOP128 %reg, %reg, %dest_reg
This optimization is enabled with -O2 and -Os.
4. 16-bit, 32-bit and 64-bit register tests with immediate may be
encoded as 8-bit register test with immediate. This optimization is
enabled with -Os.
These optimizations were intended for compiler generated assembly codes.
The optimization changes may take a long time to be put into GCC. The
similar SSE move encoding optimization for GCC was first proposed in
Feb, 2019:
https://gcc.gnu.org/pipermail/gcc-patches/2019-February/516941.html
It finally went in Mar, 2020:
commit 5358e8f5800daa0012fc9d06705d64bbb21fa07b
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Thu Mar 5 16:45:05 2020 -0800
i386: Properly encode vector registers in vector move
Such optimizations are useful for compiler generated codes since they
work with released versions of GCC which don't have such optimized
encoding. We assume that it is safe to use on compiler generated codes.
When we are informed that an assembler optimization introduces a
significant drawback, we will investigate its drawbacks and benefits.
If its drawbacks outweigh its benefits, such optimization should be
removed.
commit 1c3c3e4b3c
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Jun 19 09:47:21 2026 +0200
x86: optimize XCHG to MOV for same-register forms
breaks valgrind:
https://bugs.kde.org/show_bug.cgi?id=522533
"xchgl %ecx,%ecx" in VALGRIND_GET_NR_CONTEXT, which is defined in
/usr/include/valgrind/valgrind.h:
#define VALGRIND_GET_NR_CONTEXT(_zzq_rlval) \
{ volatile OrigFn* _zzq_orig = &(_zzq_rlval); \
volatile unsigned int __addr; \
__asm__ volatile(__SPECIAL_INSTRUCTION_PREAMBLE \
/* %EAX = guest_NRADDR */ \
"xchgl %%ecx,%%ecx" \
: "=a" (__addr) \
: \
: "cc", "memory" \
); \
_zzq_orig->nraddr = __addr; \
}
has special meanings and shouldn't be changed by assembler even when
assembler optimization is enabled. Since there are no any evidences
to show its benefits, we can't say that it is useful at all. This
patch disables this optimization, which may be enabled with a different
option.
gas/
PR gas/34343
* config/tc-i386.c (optimize_for_disabled_optimizations): New.
(optimize_encoding): Optimize "xchg %rN, %rN" to "mov %rN, %rN"
only if optimize_for_disabled_optimizations isn't 0.
* testsuite/gas/i386/optimize-2b.d: Updated.
* testsuite/gas/i386/x86-64-optimize-3b.d: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Consider test.c:
...
1 namespace mod_a {
2 int xxx = 10;
3 }
4
5 static inline int __attribute__((always_inline))
6 inlined () {
7 return 0;
8 }
9
10 int main () {
11 using namespace mod_a;
12 int res = inlined ();
13 return res + xxx;
14 }
...
compiled with "g++ test.c -g".
Trying to print variable xxx at line 12 fails:
...
$ gdb -q -batch a.out -ex start -ex "p xxx"
...
Temporary breakpoint 1, main () at test.c:12
12 int res = inlined ();
No symbol "xxx" in current context.
...
The problem is here in function using_direct::valid_line:
...
CORE_ADDR curr_pc = get_frame_pc (get_selected_frame (nullptr));
symtab_and_line curr_sal = find_sal_for_pc (curr_pc, 0);
return (decl_line <= curr_sal.line)
|| (decl_line >= boundary);
...
where we're trying to decide whether "using namespace mod_a" is applicable.
The decl_line is 11, as expected.
If curr_sal.line were 12, decl_line <= curr_sal.line would be true, and
using_direct::valid_line would return true.
But instead, curr_sal.line is 7.
This is sort of correct, the current PC maps to that line. It's just that gdb
steps into inlined functions in two steps, each with identical PC:
- once stopping at the call site (line 12 in this case)
- once stopping at the PC line (line 7 in this case)
The function using_direct::valid_line doesn't apply this logic, and
consequently line 7 is used for both cases.
Fix this by using find_frame_sal instead.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34201
Consider test.c:
...
1 namespace mod_a {
2 int xxx = 10;
3 }
4
5 static void
6 foo ()
7 {
8 }
9
10 int
11 main ()
12 {
13 {
14 foo ();
15 using namespace mod_a;
16 }
17
18 return mod_a::xxx;
19 }
...
compiled with "g++ test.c -g".
Attempting to print xxx at line 14 shouldn't find anything (because it's
before the "using namespace mod_a"), but it does:
...
$ gdb -q -batch a.out -ex start -ex "p xxx"
...
Temporary breakpoint 1, main () at test.c:14
14 foo ();
$1 = 10
...
This happens because using_direct::valid_line returns true here:
...
return (decl_line <= curr_sal.line)
|| (decl_line >= boundary);
...
Since we have decl_line == 15 and curr_sal.line == 14,
"(decl_line <= curr_sal.line)" evaluates to false.
But boundary == 14, so "(decl_line >= boundary)" evaluates to true.
The "(decl_line >= boundary)" bit was added as a workaround for
GCC PR debug/108716.
Since I'm using GCC 15, the workaround is not needed.
Fix this by limiting the workaround to broken GCC versions.
Tested on x86_64-linux, using GCC 15.2, and 7.5.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34203
On x86_64-linux, I ran into the following FAIL:
...
(gdb) cont
Continuing.
[Switching to Thread 0x7ffff7cbe6c0 (LWP 3534988)]
Thread 2 "sw-watchpoint-s" hit Watchpoint 3: watched_global
Old value = 0
New value = 1
0x00007ffff7d514bf in futex_wait () at ../sysdeps/nptl/futex-internal.h:146
146 int err = lll_futex_timed_wait (futex_word, expected, NULL, private);
(gdb) PASS: $exp: target-non-stop=auto: displaced-stepping=auto: \
continue to watchpoint
break 64
No compiled code for line 64 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) FAIL: $exp: target-non-stop=auto: displaced-stepping=auto: \
gdb_breakpoint: set breakpoint at 64
...
[ The FAIL initially reproduced only under heavy system load (simulated using
stress -c $(grep -c ^processor: /proc/cpuinfo)), but then I found that
changing the delay in $srcfile from 1 second to 1 millisecond also reproduced
it fairly reliably. Using this approach, I managed to reproduce both on
x86_64-linux and aarch64-linux. ]
The test-case tries to set a breakpoint at $srcfile:64, using just "64", but
that doesn't work because the inferior is not stopped in $srcfile.
This can be trivially fixed by using $srcfile:64 instead, and indeed, this is
what this patch does.
However, that fix is only correct if gdb is indeed allowed to report a stop in
thread 2.
This is a question I found difficult to answer.
I found some text in the docs [1] that seems related to the test-case
scenario:
...
Warning: In multi-threaded programs, software watchpoints have only limited
usefulness. If GDB creates a software watchpoint, it can only watch the value
of an expression in a single thread. If you are confident that the expression
can only change due to the current thread’s activity (and if you are also
confident that no other thread can become current), then you can use software
watchpoints as usual. However, GDB may not notice when a non-current thread’s
activity changes the expression. (Hardware watchpoints, in contrast, watch an
expression in all threads.)
...
After reading this text, my impression was that gdb shouldn't report a stop in
thread 2, because:
- GDB "can only watch the value of an expression in a single thread",
- the expression can only change due the current thread's activity (thread 1),
and
- thread 2 cannot become current, it just spins and there's no breakpoint set
in the range where it spins.
However, in the test-case I came across the following text:
...
# The final continue, with the software watchpoint set, so that
# GDB single-steps all threads (if the target is non-stop).
...
Indeed, the test-case iterates over some dimensions:
...
foreach_with_prefix target-non-stop {auto on off} {
foreach_with_prefix displaced-stepping {auto on off} {
test ${target-non-stop} ${displaced-stepping}
}
}
...
and disregarding the auto, the FAIL reproduces with both displaced-stepping on
and off, but only with target-non-stop on.
So we have the default non-stop off, and target-non-stop on.
The documentation says about this [2]:
...
set non-stop off, target operating in non-stop mode
When a thread hits a breakpoint, finishes a step, etc., the target does not
immediately stop all other threads. If, while processing the event, infrun
decides the stop should be reported to the user, it then explicitly stops all
threads, just before presenting the stop to the user; otherwise, infrun
re-resumes the stopped thread. This scenario is also called “all-stop on top
of non-stop”.
...
I was not able to deduce why in this situation and in presence of a software
watchpoint all threads should be single stepping, so I asked Claude Code.
It gave the following background information:
- in the pure all-stop case (set non-stop off, target operating in all-stop
mode), in presence of a software watchpoint:
- the current thread single-steps
- the other threads stay stopped
- consequently, only modifications by the current thread are detected,
- in the all-stop on non-stop case (set non-stop off, target operating in
non-stop mode), in presence of a software watchpoint:
- all threads single-step
- consequently, modifications by any thread are detected, but it's not
possible to attribute the modification to any specific thread, so gdb
attributes it to the thread whose stop happens to be processed.
This adequately explains the behavior in the test-case.
I suspect that the warning text in the documentation needs updating, because
AFAICT it doesn't cover the "set non-stop off, target operating in non-stop
mode" behavior described above.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34280
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Set-Watchpoints.html
[2] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Maintenance-Commands.html#index-maint-set-target_002dnon_002dstop-mode-_005bon_007coff_007cauto_005d
In commit 6c85ef111b ("[gdb] Use using instead of typedef"), I did:
...
-typedef long __attribute__ ((__aligned__ (4))) compat_x32_clock_t;
+using compat_x32_clock_t = long __attribute__ ((__aligned__ (4)));
...
which I had to revert because clang ignores the attribute in this variant.
Pedro suggested instead using:
...
using compat_x32_clock_t [[gnu::aligned (4)]] = long;
...
which does work with both clang and gcc.
[ Note that it's not a question of how the attribute is worded, this also works:
...
using compat_x32_clock_t __attribute__ ((__aligned__ (4))) = long;
...
It's just a question of where the attribute is placed. ]
Fix this by using Pedro's suggestion.
Suggested-By: Pedro Alves <pedro@palves.net>
Approved-By: Tom Tromey <tom@tromey.com>
Convert "typedef struct foo { ... } bar" into "using bar = struct foo { ... }".
Variant where typedef is on its own line.
Generated by a script written by Claude Code.
Approved-By: Tom Tromey <tom@tromey.com>
Convert "typedef struct foo { ... } *bar" to
"struct foo { ... }; using bar = foo *".
Generated by a script written by Claude Code.
Approved-By: Tom Tromey <tom@tromey.com>
Convert "typedef struct foo { ... } bar" to "using bar = struct foo { ...}".
Generated by a script written by Claude Code.
Approved-By: Tom Tromey <tom@tromey.com>
Convert "typedef struct foo { ... } foo" into "struct foo { ... }".
Generated by a script written by Claude Code.
Approved-By: Tom Tromey <tom@tromey.com>
Transform "typedef void (*foo) ()" into "using foo = void (*) ()".
Generated by a script written by Claude Code.
Approved-By: Tom Tromey <tom@tromey.com>
