gdb: only insert thread-specific breakpoints in the relevant inferior
added a couple of calls to breakpoint::clear_locations() inside
update_breakpoint_locations().
The intention of these calls was to avoid leaving redundant locations
around when a thread- or inferior-specific breakpoint was switched
from one thread or inferior to another.
Without the clear_locations() calls the tests gdb.multi/tids.exp and
gdb.multi/pending-bp.exp have some failures. A b/p is changed such
that the program space it is associated with changes. This triggers a
call to breakpoint_re_set_one() but the FILTER_PSPACE argument will be
the new program space. As a result GDB correctly calculates the new
locations and adds these to the breakpoint, but the old locations, in
the old program space, are incorrectly retained. The call to
clear_locations() solves this by deleting the old locations.
However, while working on another patch I realised that the approach
taken here is not correct. The FILTER_PSPACE argument passed to
breakpoint_re_set_one() and then on to update_breakpoint_locations()
might not be the program space to which the breakpoint is associated.
Consider this example:
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) start
Temporary breakpoint 1 at 0x401198: file hello.c, line 18.
Starting program: /tmp/hello.x
Temporary breakpoint 1, main () at hello.c:18
18 printf ("Hello World\n");
(gdb) break main thread 1
Breakpoint 2 at 0x401198: file hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000401198 in main at hello.c:18
stop only in thread 1
(gdb) add-inferior -exec /tmp/hello.x
[New inferior 2]
Added inferior 2 on connection 1 (native)
Reading symbols from /tmp/hello.x...
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y <PENDING> main
stop only in thread 1.1
Notice that after creating the second inferior and loading a file the
thread-specific breakpoint was incorrectly made pending. Loading the
exec file in the second inferior triggered a call to
breakpoint_re_set() with the new, second, program space as the
current_program_space.
This program space ends up being passed to
update_breakpoint_locations().
In update_breakpoint_locations this condition is true:
if (all_locations_are_pending (b, filter_pspace) && sals.empty ())
and so we end up discarding all of the locations for this breakpoint,
making the breakpoint pending.
What we really want to do in update_breakpoint_locations() is, for
thread- or inferior- specific breakpoints, delete any locations which
are associated with a program space that this breakpoint is NOT
associated with.
But then I realised the answer was easier than that.
The ONLY time that a b/p can have locations associated with the
"wrong" program space like this is at the moment we change the thread
or inferior the b/p is associated with by calling
breakpoint_set_thread() or breakpoint_set_inferior().
And so, I think the correct solution is to hoist the call to
clear_locations() out of update_breakpoint_locations() and place a
call in each of the breakpoint_set_{thread,inferior} functions.
I've done this, and added a couple of new tests. All of which are
now passing.
Tom de Vries [Tue, 8 Oct 2024 11:45:21 +0000 (13:45 +0200)]
[gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with read1+readnow
When running test-case gdb.ada/tagged-lookup.exp with target board readnow and
make target check-read1:
...
$ ( cd build/gdb; \
make check-read1 \
RUNTESTFLAGS="--target_board=readnow gdb.ada/tagged-lookup.exp" )
...
I run into:
...
(gdb) PASS: gdb.ada/tagged-lookup.exp: set debug symtab-create 1
print *the_local_var^M
$1 = (n => 2)^M
(gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded
...
The problem is that the corresponding gdb_test_multiple uses line-by-line
matching (using -lbl) which doesn't work well with the multiline pattern
matching both the prompt and the line before it:
...
-re -wrap ".* = \\\(n => $decimal\\\)" {
...
Fix this by making it a one-line pattern:
...
-re -wrap "" {
...
While we're at it, replace an if-then-pass-else-fail with a gdb_assert.
Tom de Vries [Tue, 8 Oct 2024 10:27:20 +0000 (12:27 +0200)]
[gdb/symtab] Fix gdb.dwarf2/enum-type-c++.exp with cc-with-debug-types
When running test-case gdb.dwarf2/enum-type-c++.exp with target board
cc-with-debug-types, we run into:
...
(gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
...
because val1 has no parent:
...
[31] ((cooked_index_entry *) 0x7efedc002e90)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xef
parent: ((cooked_index_entry *) 0)
Fix this by:
- adding a cooked index entry for DIE 0xcb (and consequently for child DIE
0xd3), by marking it interesting,
- making sure that the entry for DIE 0xcb has a name, and
- using the entry for DIE 0xd3 as parent entry for DIE 0xdd.
Tom de Vries [Tue, 8 Oct 2024 10:27:20 +0000 (12:27 +0200)]
[gdb/symtab] Fix parent of enumerator
As mentioned in commit 489b82720f5 ('[gdb/symtab] Revert "Change handling of
DW_TAG_enumeration_type in DWARF scanner"'), when doing "maint print objfiles" in
test-case gdb.dwarf2/enum-type.exp, for val1 we get an entry without parent:
...
[27] ((cooked_index_entry *) 0x7fbbb4002ef0)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x124
parent: ((cooked_index_entry *) 0)
...
This happens here in cooked_indexer::index_dies:
...
info_ptr = recurse (reader, info_ptr,
is_enum_class ? this_entry : parent_entry,
fully);
...
when we're passing down a nullptr parent_entry, while the parent of this_entry
is deferred.
Fix this in cooked_indexer::index_dies by passing down a deffered parent
instead, such that we get:
...
[27] ((cooked_index_entry *) 0x7ff0e4002ef0)^M
name: val1^M
canonical: val1^M
qualified: ns::val1^M
DWARF tag: DW_TAG_enumerator^M
flags: 0x0 []^M
DIE offset: 0x124^M
parent: ((cooked_index_entry *) 0x7ff0e4002f20) [ns]^M
...
Tom de Vries [Tue, 8 Oct 2024 06:24:13 +0000 (08:24 +0200)]
[gdb/contrib] Add more separators in spellcheck.sh
Add two more separators in spellcheck.sh: colon and comma.
Doing so triggers the "inbetween->between" rule, which gives an incorrect
result. Override this with "inbetween->between, in between, in-between" [1],
in a new file gdb/contrib/common-misspellings.txt.
Fix the following common misspellings:
...
everytime -> every time
sucess -> success
thru -> through
transfered -> transferred
inbetween -> between, in between, in-between
...
Verified with spellcheck.sh. Tested on x86_64-linux.
Tom de Vries [Tue, 8 Oct 2024 06:24:13 +0000 (08:24 +0200)]
[gdb/contrib] Factor out grep_or and sed_or in spellcheck.sh
While trying to add more separators here:
...
# Separators: space, slash, tab.
grep_separator=" |/| "
sed_separator=" \|/\|\t"
...
I mistakingly used "|" instead of "\|" in sed_separator.
Factor out new variables grep_or and sed_or, and construct the grep_separator
and sed_separator variables by joining the elements of a list using grep_or
and sed_or.
Verified with shellcheck, and tested by rerunning on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Alan Modra [Mon, 7 Oct 2024 23:35:39 +0000 (10:05 +1030)]
Revised "Don't return (null) from bfd_elf_sym_name"
Commit 68bbe1183379 results in a lot of follow up work, much of which
likely is still to be done. (And yes, since this is all for corrupted
or fuzzed object files, a whole lot of work doesn't much benefit
anyone. It was a bad idea to put NULL in asymbol->name.) So I'm
changing the approach to instead put a unique empty string for symbols
with a corrupted st_name. An empty string won't require much work to
ensure nm, objcopy, objdump etc. won't crash, since these tools
already must work with unnamed local symbols.
The unique empty string is called bfd_symbol_error_name. This patch
uses that name string for corrupted symbols in the ELF and COFF
backends. Such symbols are displayed by nm and objdump as the
translated string "<corrupt>", which is what the COFF backend used to
put directly into corrupted symbols.
ie. it's the way I should have written the original patch, plus a few
tides and cleanups I retained from the reverted patches.
gprofng: add hardware counters for Neoverse-N1 and Ampere-1 processors
gprofng/ChangeLog
2024-10-03 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
* common/hwc_cpus.h: New constant for Neoverse-N1 and Ampere-1.
* common/hwctable.c: Add the hwc table for Neoverse-N1 and Ampere-1.
* src/hwc_arm_ampere_1.h: New file with hwc table for Ampere-1.
* src/hwc_arm_neoverse_n1.h: New file with hwc table for Neoverse-N1.
Andreas Schwab [Thu, 13 Jun 2024 17:41:13 +0000 (19:41 +0200)]
m68k: Support for jump visualization in disassembly
opcodes/
* m68k-dis.c (m68k_opcode_to_insn_type): Define.
(match_insn_m68k): Call it to set insn_type.
(print_insn_arg) [case 'B']: Set branch target address.
(print_insn_m68k): Set insn_info_valid.
Tom de Vries [Mon, 7 Oct 2024 08:44:45 +0000 (10:44 +0200)]
[gdb/testsuite] Fix gdb.python/py-inferior.exp with -fsanitize=thread
With a gdb build with -fsanitize=thread, and test-case
gdb.python/py-inferior.exp I run into:
...
(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)^M
ERROR: ThreadSanitizer: requested allocation size 0xffffffffffffffff exceeds \
maximum supported size of 0x10000000000^M
...
There's already a workaround for this using ASAN_OPTIONS, and apparently the
same is needed for TSAN_OPTIONS.
Add the allocator_may_return_null=1 workaround also in TSAN_OPTIONS.
Gaius Mulley [Sun, 6 Oct 2024 19:40:59 +0000 (20:40 +0100)]
gdb/m2: add builtin procedure function ADR
This patch introduces ADR to the Modula-2 language interface.
It return the address of the parameter supplied.
The patch also contains a dejagnu test for ADR.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tom de Vries [Sun, 6 Oct 2024 05:59:48 +0000 (07:59 +0200)]
[gdb/contrib] Add spellcheck.sh
I came across a table containing common misspellings [1], and wrote a script to
detect and correct these misspellings.
The table also contains entries that have alternatives, like this:
...
addres->address, adders
...
and for those the script prints a TODO instead.
The script downloads the webpage containing the table, extracts the table and
caches it in .git/wikipedia-common-misspellings.txt to prevent downloading it
over and over again.
Example usage:
...
$ gdb/contrib/spellcheck.sh gdb*
...
ChangeLog files are silently skipped.
Checked with shellcheck.
Tested on x86_64-linux, by running it on the gdb* dirs on doing a build and
test run.
The results of running it are in the two following patches.
Reviewed-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines
Alan Modra [Thu, 3 Oct 2024 22:17:05 +0000 (07:47 +0930)]
gdb segv in elfread.c:elf_rel_plt_read
After commit 68bbe1183379, ELF symbols read via bfd_canonicalize_symtab
and similar functions which have bad st_name fields will have NULL in
the name rather than "(null)". gdb.base/bfd-errors.exp deliberately
creates a faulty shared library with st_name pointing outside of
.dynsym for some symbols, and thus now results in NULL symbol names.
This triggers a segv on string_buffer.assign(name). Fix that.
Alan Modra [Fri, 4 Oct 2024 07:07:35 +0000 (16:37 +0930)]
bfd_elf_sym_name_raw
Many uses of bfd_elf_sym_name report errors. They ought to not return
a NULL, as was the case prior to commit 68bbe1183379. Introduce a new
function for cases where we'd like to know there is a problem with a
symbol st_name.
* elf-bfd.h (bfd_elf_sym_name_raw): Declare.
* elf.c (bfd_elf_sym_name_raw): New function.
(bfd_elf_sym_name): Revert to behaviour prior to 68bbe1183379,
but returning "<null>" rather than "(null)" for st_name errors.
(group_signature): Use bfd_elf_sym_name_raw.
* elfcode.h (elf_slurp_symbol_table): Likewise.
* elf32-i386.c (elf_i386_scan_relocs): Whitespace.
Jan Beulich [Fri, 4 Oct 2024 07:42:13 +0000 (09:42 +0200)]
x86: prune OBJ_MAYBE_... uses
With the removal of emulations, OBJ_MAYBE_... can no longer be defined.
Tidy code wherever they're used, which also includes the dropping of
most IS_ELF and uses and checks of OUTPUT_FLAVOR.
Where touching such constructs anyway, also drop TE_PEP checks when used
together with TE_PE ones (the former implies the latter).
Jan Beulich [Fri, 4 Oct 2024 07:41:38 +0000 (09:41 +0200)]
x86: drop largely defunct gas emulations
Both ELF and COFF have various sub-flavors, each of which would then
require its own emulation: Right now when configuring a COFF/PE
secondary target (with perhaps an ELF primary one), one gets plain COFF
emulation rather than COFF/PE one.
As such a multitude of emulations would be unwieldy (and likely fragile)
drop gas emulations altogether instead.
While originally this was in preparation of a subsequent change making
SUPPORT_FRAME_LINKONCE potentially dependent on a global variable, the
construct appears unlikely to have been correct in the first place: The
variable would have been passed reliably uninitialized when
SUPPORT_FRAME_LINKONCE is build-time true.
While there correct indentation of the parameters passed to
get_cfi_seg().
Jan Beulich [Fri, 4 Oct 2024 07:36:24 +0000 (09:36 +0200)]
gas: put emul decls in emul.h
The individual struct emulation instances shouldn't be declared in a .c
file; it and the producers of the symbols want to both see the
declarations, so declarations and definitions don't go out of sync. Move
these declarations to emul.h.
While there also adjust the conditional around this_format: That symbol
is never #define-d anywhere, and it's needed only when USE_EMULATIONS is
defined. (Really, when obj-multi isn't in use, it also is effectively
only ever written to.)
Jan Beulich [Fri, 4 Oct 2024 07:34:11 +0000 (09:34 +0200)]
MAINTAINERS: move M R Swami Reddy to Past Maintainers
He/she cannot be reached at the given address anymore, and the name is
apparently too common to identify the person to attempt to establish
another contact. Sadly this orphans the CR16 and CRx ports.
Jan Beulich [Fri, 4 Oct 2024 07:33:49 +0000 (09:33 +0200)]
MAINTAINERS: move Matt Thomas to Past Maintainers
Matt cannot be reached at the @netbsd.org address anymore, and I was
unable to find another one, even with the help of the NetBSD community
(where his resigning was announced over 4 years ago [1]).
when I disable a breakpoint in VS Code the breakpoint is removed
instead. I compared the behavior to lldb-dap and disabled events when
removing a breakpoint. Now it is possible to disable and enable
breakpoints in VS Code.
Alexey Izbyshev [Wed, 2 Oct 2024 19:58:08 +0000 (22:58 +0300)]
bfd: fix unnecessary bfd.info regen
When building from an unmodified release tarball, a REGEN_TEXI
invocation is supposed to create a symlink to the .texi file
in the source directory and discard the newly generated .tmp file.
However, after commit bd32be01c997 ("bfd: merge doc subdir up a level")
it creates the symlink at the wrong level, and then a .texi with
a fresh timestamp, which in turn forces bfd.info regeneration.
This breaks builds in environments without makeinfo program.
Fix this by creating the symlink at the level of the target stamp.
Fixes: bd32be01c997 ("bfd: merge doc subdir up a level") Signed-off-by: Alexey Izbyshev <izbyshev@ispras.ru>
Alan Modra [Wed, 2 Oct 2024 05:09:02 +0000 (14:39 +0930)]
Enable dlltool --leading-underscore for targets other than x86
This also makes the dlltool tests run more PE targets, finding that
sh-pe dlltool reports "Machine 'sh' not supported". I guess no one
cares about that.
PR19459
* dlltool.c (asm_prefix): Remove "mach" parameter. Return
leading_underscore independent of machine.
(ASM_PREFIX): Adjust.
* testsuite/binutils-all/dlltool.exp: Run on any target
satisfying is_pecoff_format for which dlltool is built.
Revert commit 0398b8d6c86a. Remove target_xfail.
Alan Modra [Wed, 2 Oct 2024 05:04:35 +0000 (14:34 +0930)]
dlltool leading_underscore
This patch tidies dlltool code dealing with adding a leading
underscore to generated symbol names. There should be no functional
change here, but there could be if we ever have a bfd target with
symbol_leading_char something other than '_' or 0.
* dlltool.c (leading_underscore): Change from an int to a
char*. Update all uses. If neither --leading-underscore or
--no=leading-underscore is given, set leading_underscore to a
string with first char returned by bfd_get_target_info as the
target's symbol underscoring.
Alan Modra [Tue, 1 Oct 2024 23:32:16 +0000 (09:02 +0930)]
nm: don't try to print line numbers for symbols without names
It doesn't make much sense trying to print line numbers for what are
usually broken symbols, and there is a possibility of a segfault if
we pass strcmp a NULL.
Alan Modra [Tue, 1 Oct 2024 04:38:08 +0000 (14:08 +0930)]
Don't return "(null)" from bfd_elf_sym_name
A NULL return from bfd_elf_string_from_elf_section indicates an error.
That shouldn't be masked by bfd_elf_sym_name but rather passed up to
callers such as group_signature. If we want to print "(null)" then
that should be done at a higher level. That's what this patch does,
except that I chose to print "<null>" instead, like readelf. If we
see "(null)" we're probably passing a NULL to printf. I haven't
changed aoutx.h or pdp11.c print_symbol functions because they already
handle NULL names by omitting the name. I also haven't changed
mach-o.c, mmo.c, som.c, srec.c, tekhex.c, vms-alpha.c and
wasm-module.c print_symbol function because it looks like they will
never have NULL symbol names.
bfd/
* elf.c (bfd_elf_sym_name): Don't turn a NULL name into a
pointer to "(null)".
(bfd_elf_print_symbol): Print "<null>" for NULL symbol names.
* coffgen.c (coff_print_symbol): Likewise.
* ecoff.c (_bfd_ecoff_print_symbol): Likewise.
* pef.c (bfd_pef_print_symbol): Likewise.
* syms.c (bfd_symbol_info): Return "<null>" in symbol_info.name
if symbol name is NULL.
ld/
* ldlang.c (ld_is_local_symbol): Don't check for "(null)"
symbol name.
Ruud van der Pas [Tue, 24 Sep 2024 19:54:54 +0000 (19:54 +0000)]
gprofng: fix a problem with hardware event counters
Fix a bug where an experiment with hardware event counter data
causes the source and disassembly files not to be generated.
No longer suppress zero valued metrics and change the name
of the man page in a warning message. Adapt line lengths to
not exceed 79.
gprofng/ChangeLog
2024-09-24 Ruud van der Pas <ruud.vanderpas@oracle.com>
PR 32193
PR 32199
PR 32201
* gp-display-html/gp-display-html.in: Implement all
the above changes.
Martin Storsjö [Fri, 20 Sep 2024 21:47:21 +0000 (00:47 +0300)]
Add support for IMPORT_NAME_EXPORTAS in ILF (MSVC style) import libraries
This import name type is formally yet undocumented, but MSVC
produces/supports it, primarily for ARM64EC import libraries.
LLVM/LLD also supports this import name type. Since recently,
llvm-dlltool also uses this type for certain kinds of renamed imports
(that are easy to do in the long style import libraries produced by
GNU dlltool, but require this name type in short import libraries).
This name type contains a third string, in addition to the symbol
name and the DLL name, indicating the actual imported name to
reference in the import tables - which now can be distinct different
from the symbol name on the object file level.
Tom Tromey [Wed, 18 Sep 2024 16:25:13 +0000 (10:25 -0600)]
Introduce and use operation::type_p
There's currently code in gdb that checks if an expression evaluates
to a type. In some spots this is done by comparing the opcode against
OP_TYPE, but other spots more correctly also compare with OP_TYPEOF
and OP_DECLTYPE.
This patch cleans up this area, replacing opcode-checking with a new
method on 'operation'.
Generally, checking the opcode should be considered deprecated,
although it's unfortunately difficult to get rid of opcodes entirely.
I also took advantage of this change to turn eval_op_type into a
method, removing a bit of indirection.
Alan Modra [Wed, 25 Sep 2024 01:12:36 +0000 (10:42 +0930)]
Re: dlltool: file name too long
Allow for "snnnnn.o" suffix when testing against NAME_MAX, and tidy
TMP_STUB handling by overwriting a prior nnnnn.o string rather than
copying the entire name.
* dlltool.c (TMP_STUB): Add "nnnnn.o" to format.
(make_one_lib_file): Localise variables. Don't copy TMP_STUB,
overwrite suffix instead.
(gen_lib_file): Similarly.
(main): Allow for max suffix when testing against NAME_MAX.
Andrew Burgess [Thu, 12 Sep 2024 09:56:54 +0000 (10:56 +0100)]
gdb: fix filename completion in the middle of a line
I noticed that filename completion in the middle of a line doesn't
work as I would expect it too. For example, assuming '/tmp/filename'
exists, and is the only file in '/tmp/' then when I do the following:
(gdb) file "/tmp/filen<TAB>
GDB completes to:
(gdb) file "/tmp/filename"
But, if I type this:
(gdb) file "/tmp/filen "xxx"
Then move the cursor to the end of '/tmp/filen' and press <TAB>, GDB
will complete the line to:
(gdb) file "/tmp/filename "xxx"
But GDB will not insert the trailing double quote character.
The reason for this is found in readline/readline/complete.c in the
function append_to_match. This is the function that appends the
trailing closing quote character, however, the closing quote is only
inserted if the cursor (rl_point) is at the end (rl_end) of the line
being completed.
In this patch, what I do instead is add the closing quote in the
function gdb_completer_file_name_quote, which is called from readline
through the rl_filename_quoting_function hook. The docs for
rl_filename_quoting_function say (see 'info readline'):
"... The MATCH_TYPE is either 'SINGLE_MATCH', if there is only one
completion match, or 'MULT_MATCH'. Some functions use this to
decide whether or not to insert a closing quote character. ..."
This is exactly what I'm doing in this patch, and clearly this is not
an unusual choice. Now after completing a filename that is not at the
end of the line GDB will add the closing quote character if
appropriate.
I have managed to write some tests for this. I send a line of text to
GDB which includes a partial filename followed by a trailing string, I
then send the escape sequence to move the cursor left, and finally I
send the tab character.
Obviously, expect doesn't actually see the complete output with the
extra text "in place", instead expect sees the original line followed
by some escape sequences to reflect the cursor movement, then an
escape sequence to indicate that text is being inserted in the middle
of a line, followed by the new characters ... it's a bit messy, but I
think it holds together.
Andrew Burgess [Fri, 13 Sep 2024 10:16:51 +0000 (11:16 +0100)]
gdb: fix for completing a second filename for a command
After the recent filename completion changes I noticed that the
following didn't work as expected:
(gdb) file "/path/to/some/file" /path/to/so<TAB>
Now, I know that the 'file' command doesn't actually take multiple
filenames, but currently (and this was true before the recent filename
completion changes too) the completion function doesn't know that the
command only expects a single filename, and should complete any number
of filenames. And indeed, this works:
(gdb) file "/path/to/some/file" "/path/to/so<TAB>
In this case I quoted the second path, and now GDB is happy to offer
completions.
It turns out that the problem in the first case is an off-by-one bug
in gdb_completer_file_name_char_is_quoted. This function tells GDB if
a character within the line being completed is escaped or not. An
escaped character cannot be a word separator.
The algorithm in gdb_completer_file_name_char_is_quoted is to scan
forward through the line keeping track of whether we are inside double
or single quotes, or if a character follows a backslash. When we find
an opening quote we skip forward to the closing quote and then check
to see if we skipped over the character we are looking for, if we did
then the character is within the quoted string.
The problem is that this "is character inside quoted string" check
used '>=' instead if '>'. As a consequence a character immediately
after a quoted string would be thought of as inside the quoted string.
In our first example this means that the single white space character
after the quoted string was thought to be quoted, and was not
considered a word breaking character. As such, GDB would not try to
complete the second path. And indeed, if we tried this:
(gdb) file "/path/to/some/file" /path/to/so<TAB>
That is, place multiple spaces after the first path, then GDB would
consider the first space as quoted, but the second space is NOT
quoted, and would be a word break. Now GDB does complete the second
path.
By changing '>=' to '>' in gdb_completer_file_name_char_is_quoted this
bug is resolved, now the original example works and GDB will correctly
complete the second path.
For testing I've factored out the core of one testing proc, and I now
run those tests multiple times, once with no initial path, once with
an initial path in double quotes, once with an initial path in
single quotes, and finally, with an unquoted initial path.
Alan Modra [Fri, 27 Sep 2024 22:33:36 +0000 (08:03 +0930)]
gas buffer overflow with --listing-rhs-width
With listings enabled, gas keeps a small cache of source lines. They
are stored in buffers of size LISTING_RHS_WIDTH, ie. 100. Given
listing-rhs-width larger than 100 it is of course possible to overflow
the buffer. Fix that by allocating as needed. We could allocate all
buffers on the first call to print_source using listing_rhs_width, but
I chose not to do that in case some future assembly directive allows
changes to listing_rhs_width similarly to the way paper_width can
change during assembly.
Simon Marchi [Mon, 12 Aug 2024 17:46:06 +0000 (13:46 -0400)]
gdb/symtab: pass program space to lookup_symtab and iterate_over_symtabs
Make the current program space references bubble up.
In collect_symtabs_from_filename, remove the calls to
set_current_program_space and just pass the relevant pspaces.
This appears safe to do, because nothing in the `collector` callback
cares about the current pspace.
Change-Id: I00a7ed484bfbe5264f01a6abf0d33b51de373cbb Reviewed-by: Keith Seitz <keiths@redhat.com>
Jan Beulich [Fri, 27 Sep 2024 09:41:27 +0000 (11:41 +0200)]
x86: fix Solaris gas testsuite run
Commits 8015b1b0c1a1 ("x86-64: Never make R_X86_64_GOT64 section
relative"), d774bf9b3623 ("x86: Add tls check in gas"), and 1b714c14e40f ("x86: Turn PLT32 to PC32 only for PC-relative
relocations") all should have adjusted the Solaris counterpart of the
reloc64 test as well.
Jan Beulich [Fri, 27 Sep 2024 09:41:00 +0000 (11:41 +0200)]
RISC-V: odd data padding vs mapping symbols
Odd data padding has a $d label inserted at its beginning. When a $x...
label is removed instead, a replacement is inserted after the padding.
The same, however, needs to also happen when there's no $x to replace.
Jan Beulich [Fri, 27 Sep 2024 09:40:22 +0000 (11:40 +0200)]
RISC-V: correct alignment directive handling for text sections
.insn or data emitted inside text sections can lead to positions not
being at insn granularity. In such situations using alignment
directives should reliably enforce the requested alignment.
Specifically requests to align back to insn granularity may not be
ignored (where, as a subcase thereof, the ordering of ".option norvc"
and e.g. ".p2align 2" should not matter; so far the alignment directive
needs to come first to have any effect). Similarly ahead of emitting
NOPs alignment first needs to be forced back to insn granularity.
The new testcases actually point out a corner case issue in the
disassembler as well, which is being corrected at the same time: We
don't want to print "0x" without any subsequent digits.
H.J. Lu [Fri, 20 Sep 2024 03:32:26 +0000 (11:32 +0800)]
ld: Ignore .note.gnu.build-id when placing orphaned notes
The commits:
e8e10743f7b Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments. bf6d7087de0 ld: Move the .note.build-id section to near the start of the memory map
place .note.gnu.build-id before text sections when --rosegment is used.
Ignore .note.gnu.build-id when placing orphaned notes if --rosegment and
-z separate-code are used together to avoid putting any note sections
between .note.gnu.build-id and text sections in the same PT_LOAD segment.
PR ld/32191
* ldlang.c (lang_insert_orphan): Ignore .note.gnu.build-id when
placing orphaned notes.
* testsuite/ld-elf/pr23658-1a.d: Pass --no-rosegment to ld.
* testsuite/ld-elf/pr23658-1c.d: Likewise.
* testsuite/ld-elf/pr23658-1e.d: New file.
* testsuite/ld-elf/pr23658-1f.d: Likewise.
* testsuite/ld-i386/i386.exp: Run PR ld/32191 test.
* testsuite/ld-i386/pr32191.d: New file.
* testsuite/ld-x86-64/lam-u48.rd: Updated.
* testsuite/ld-x86-64/lam-u57.rd: Likewise.
* testsuite/ld-x86-64/pr32191-x32.d: New file.
* testsuite/ld-x86-64/pr32191.d: Likewise.
* testsuite/ld-x86-64/pr32191.s: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run PR ld/32191 tests.
Jan Beulich [Thu, 26 Sep 2024 10:25:45 +0000 (12:25 +0200)]
x86: templatize SIMD FP arithmetic templates
Reduce redundancy, in preparation of the addition of further counterparts
for AVX10.2. Provide the "ne" parameter needed there right away, even if
unused for now.
Andrew Burgess [Wed, 25 Sep 2024 14:44:56 +0000 (15:44 +0100)]
gdb/testsuite: test for memory leaks in gdb.Inferior.read_memory()
For a long time Fedora GDB has carried an out of tree patch which
checks for memory leaks in gdb.Inferior.read_memory(). At one point
in the distant past GDB did have a memory leak in this code, but this
was first fixed in commit:
* python/py-inferior.c (infpy_read_memory): Remove cleanups and
explicitly free 'buffer' on exit paths. Decref 'membuf_object'
before returning.
And the code has changed a lot since then, but the leak is still
fixed. Unfortunately, this commit didn't have any associated tests.
The original Fedora test wasn't really suitable for upstream, it was
reading /proc/PID/... to figure out if there was a leak or not.
However, we already have gdb.python/py-inferior-leak.exp in upstream
GDB, which makes use of the Python tracemalloc module to check for
memory leaks in a corner of the Python API, so I figured it wouldn't
hurt to rewrite the test in the same style.
And so here is a test for a bug which was closed 12 years ago. This
detects if the gdb.Inferior.read_memory() call leaks any memory.
I've tested this by hacking gdbpy_buffer_to_membuf, replacing the last
line which currently looks like this:
The use of "release" here will mean we no longer decrement the
reference count on membuf_obj before returning from the function. As
a consequence the membuf_obj will not be garbage collected. With this
hack in place the new test will fail.
The Python script in the new test is mostly a copy&paste from
py-inferior-leak.py with the core changed to do a memory read instead
of inferior creation. I did consider rewriting both tests into a
single file, maybe, py-memory-leak.py, which would make it easier to
add additional similar tests in the future. For now I've held off
doing that, but if this gets merged then I _might_ revisit this idea.
If folk feel that this new test should only be accepted if I do this
rewrite then let me know and I can get that done.
On copyright date ranges: The .exp and .py scripts are new enough for
this commit that I've dated them 2024. The .c source script is lifted
directly from the old Fedora patch, so I've retained the original 2014
start date for that file only.
projects / thirdparty / binutils-gdb.git / log
