This reverts commit 98bcde5e26. This
commit was causing build problems on at least sparc, ppc, and s390,
though I suspect some other targets might be impacted too.
While for executables properly aligning sections within the file can be
quite relevant, the same is of pretty little importance for relocatable
object files. Avoid passing "true" into
_bfd_elf_assign_file_position_for_section() when dealing with object
files, but compensate minimally by applying log_file_align in such
cases as a cap to the alignment put in place.
In disassembler part, for vnni instructions, we extended previous
VEX part using %XE in disassembler to promote them to EVEX by reusing
the original VEX table. For vmpsadbw, we will also use %XE. However,
it is hard to reuse the VEX table, so we are using new ones.
In assmbler part, we put the vnni table entries with previous vnni
instructions since they are just promotion from AVX-VNNI-INT{8,16}.
Since we will prefer VEX encoding, we need to use the different table
order in template <vnni>, which prefers EVEX due to earlier introduction
for AVX512_VNNI than AVX_VNNI. This means a new <vnni>. For vdpphps
and vmpsadbw, we put them at the end of the table, with future AVX10.2
instructions.
Nit: I will remove the arch requirement for avx_vnni_int{8,16} in
evex-promote testcases after AVX10.2 implies AVX-VNNI-INT{8,16}.
gas/Changelog:
* testsuite/gas/i386/i386.exp: Add AVX10.2 tests.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-256-1-intel.d: New.
* testsuite/gas/i386/avx10_2-256-1.d: Ditto.
* testsuite/gas/i386/avx10_2-256-1.s: Ditto.
* testsuite/gas/i386/avx10_2-512-1-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-512-1.d: Ditto.
* testsuite/gas/i386/avx10_2-512-1.s: Ditto.
* testsuite/gas/i386/avx10_2-promote.d: Ditto.
* testsuite/gas/i386/avx10_2-promote.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-1-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-1.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-1.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-1-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-1.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-1.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-promote.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-promote.s: Ditto.
opcodes/Changelog:
* i386-dis-evex-prefix.h: Adjust PREFIX_EVEX_0F3852.
Add PREFIX_EVEX_0F3A42_W_0.
* i386-dis-evex-w.h: Adjust EVEX_W_0F3A42.
* i386-dis-evex.h: Add table pass for AVX10.2
instructions.
* i386-dis.c: Adjust PREFIX_VEX_0F3850_W_0, PREFIX_VEX_0F3851_W_0,
PREFIX_VEX_0F38D2_W_0 and PREFIX_VEX_0F38D3_W_0.
* i386-opc.tbl: Add AVX10.2 instructions.
* i386-mnem.h: Regenerated.
* i386-tbl.h: Ditto.
Co-authored-by: Lili Cui <lili.cui@intel.com>
On a Windows machine I built gdbserver, configured for the target
'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with
support for all target (--enable-targets=all).
On the Windows machine I start gdbserver with a small test binary:
$ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe
On the GNU/Linux machine I start GDB without the test binary, and
connect to gdbserver.
As I have not given GDB the test binary, my expectation is that GDB
would connect to gdbserver and then download the file over the remote
protocol, but instead I was presented with this message:
(gdb) target remote 192.168.129.25:54321
Remote debugging using 192.168.129.25:54321
warning: C:\some\directory\executable.exe: No such file or directory.
0x00007ffa3e1e1741 in ?? ()
(gdb)
What I found is that if I told GDB where to find the binary, like
this:
(gdb) file target:C:/some/directory/executable.exe
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading C:/some/directory/executable.exe from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading C:/some/directory/executable.exe from remote target...
Reading symbols from target:C:/some/directory/executable.exe...
(gdb)
then GDB would download the executable.
I eventually tracked the problem down to exec_file_find (solib.c).
The remote target was passing an absolute Windows filename (beginning
with "C:/" in this case), but in exec_file_find GDB was failing the
IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as
relative.
The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that
the file system kind was "unix", and as the filename didn't start with
a "/" it assumed the filename was not absolute.
But I'm connecting to a Windows target, my 'target-file-system-kind'
was set to "auto", so should be figuring out that my file-system is
"dos-based".
Looking in effective_target_file_system_kind (filesystem.c), we find
that the logic of "auto" is delegated to the current gdbarch. However
in windows-tdep.c we see:
set_gdbarch_has_dos_based_file_system (gdbarch, 1);
So if we are using a Windows gdbarch we should have "dos-based"
filesystems. What this means is that after connecting to the remote
target GDB has selected the wrong gdbarch.
What's happening is that the target description sent back by the
remote target only includes the x86-64 registers. There's no
information about which OS we're on. As a consequence, GDB picks the
first x86-64 gdbarch which can handle the provided register set, which
happens to be a GNU/Linux gdbarch.
And indeed, there doesn't appear to be anywhere in gdbserver that sets
the osabi on the target descriptions, though some target descriptions
do have their osabi set when the description is created, e.g. in:
gdb/arch/amd64.c - Sets GNU/Linux osabi when appropriate.
gdb/arch/i386.c - Likewise.
gdb/arch/tic6x.c - Always set GNU/Linux osabi.
Most target descriptions are created without an osabi, gdbserver does
nothing to fix this, and the description is returned to GDB without an
osabi included.
I propose that we always set the osabi name on the target descriptions
returned from gdbserver. We could try to do this when the description
is first created, but that would mean passing extra flags into the
tdesc creation code (or just passing the osabi string in), and I don't
think that's really necessary. If we consider the tdesc creation as
being about figuring out which registers are on the target, then it
makes sense that the osabi information is injected later.
So what I've done is require the osabi name to be passed to the
init_target_desc function. This is called, I believe, for all
targets, in the gdbserver code.
Now when I connect to the Windows remote the target description
returned includes the osabi name. With this extra information GDB
selects the correct gdbarch object, which means that GDB understands
the target has a "dos-based" file-system. With that correct GDB
understands that the filename it was given is absolute, and so fetches
the file from the remote as we'd like.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
There is a single declaration of set_tdesc_osabi that is shared
between gdbserver/ and gdb/, this declaration takes a 'const char *'
argument which is the string representing an osabi.
Then in gdb/ we have an overload of set_tdesc_osabi which takes an
'enum gdb_osabi'.
In this commit I change the shared set_tdesc_osabi to be the version
which takes an 'enum gdb_osabi', and I remove the version which takes
a 'const char *'. All users of set_tdesc_osabi are updated to pass an
'enum gdb_osabi'.
The features/ code, which is generated from the xml files, requires a
new function to be added to osabi.{c,h} which can return a string
representation of an 'enum gdb_osabi'. With that new function in
place the features/ code is regenerated.
This change is being made to support the next commit. In the next
commit gdbserver will be updated to call set_tdesc_osabi in more
cases. The problem is that gdbserver stores the osabi as a string.
The issue here is that a typo in the gdbserver/ code might go
unnoticed and result in gdbserver sending back an invalid osabi
string.
To fix this we want gdbserver to pass an 'enum gdb_osabi' to the
set_tdesc_osabi function. With that requirement in place it seems to
make sense if all calls to set_tdesc_osabi pass an 'enum gdb_osabi'.
There should be no user visible changes after this commit.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In future commits I want to call set_tdesc_osabi from gdbserver/
code. Currently the only version of set_tdesc_osabi available to
gdbserver takes a string representing the osabi.
The problem with this is that, having lots of calls to set_tdesc_osabi
which all take a string is an invite for a typo to slip in. This typo
could potentially go unnoticed until someone tries to debug the wrong
combination of GDB and gdbserver, at which point GDB will fail to find
the correct gdbarch because it doesn't understand the osabi string.
It would be better if the set_tdesc_osabi calls in gdbserver could
take an 'enum gdb_osabi' value and then convert this to the "correct"
string internally. In this way we are guaranteed to always have a
valid, known, osabi string.
This commit splits the osabi related code, which currently lives
entirely on the GDB side, between gdb/ and gdbsupport/. I've moved
the enum definition along with the array of osabi names into
gdbsupport/. Then all the functions that access the names list, and
which convert between names and enum values are also moved.
I've taken the opportunity of this move to add a '.def' file which
contains all the enum names along with the name strings. This '.def'
file is then used to create 'enum gdb_osabi' as well as the array of
osabi name strings. By using a '.def' file we know that the enum
order will always match the name string array.
This commit is just a refactor, there are no user visible changes
after this commit. This commit doesn't change how gdbserver sets the
target description osabi string, that will come in the next commit.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
There are two versions of the set_tdesc_osabi function in GDB:
void
set_tdesc_osabi (struct target_desc *target_desc, const char *name)
{
set_tdesc_osabi (target_desc, osabi_from_tdesc_string (name));
}
void
set_tdesc_osabi (struct target_desc *target_desc, enum gdb_osabi osabi)
{
target_desc->osabi = osabi;
}
In the gdb/features/ files we call the second of these functions, like
this:
set_tdesc_osabi (result.get (), osabi_from_tdesc_string ("GNU/Linux"));
This can be replaced with a call to the first set_tdesc_osabi
function, so lets do that. I think that this makes the features/ code
slightly simpler and easier to understand.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Convert target_desc::arch and target_desc::osabi from 'const char*' to
gdb::unique_xmalloc_ptr<char>. This also allows us to remove the user
defined ~target_desc destructor.
I doubt it ever actually occurred, but in theory at least, there was a
memory leak in set_tdesc_architecture and set_tdesc_osabi where the
member variables were assigned without freeing any previous
value... but I suspect that usually these fields are only set once.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into:
...
(gdb) awatch a^M
Can't set read/access watchpoint when hardware watchpoints are disabled.^M
(gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint
rwatch b^M
Can't set read/access watchpoint when hardware watchpoints are disabled.^M
(gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint
continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M
(gdb) FAIL: $exp: continue until exit
...
Using "maint info break", we can see that the two failed attempts to set a
watchpoint each left behind a stale "watchpoint scope" breakpoint:
...
-5 watchpoint scope del y 0xf7ec569a inf 1
-5.1 y 0xf7ec569a inf 1
stop only in stack frame at 0xfffef4f8
-6 watchpoint scope del y 0xf7ec569a inf 1
-6.1 y 0xf7ec569a inf 1
stop only in stack frame at 0xfffef4f8
...
The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the
same happens if we:
- have can-use-hw-watchpoints == 1,
- set one of the watchpoints, and
- continue to exit.
The problem is missing symbol info on libc which is supposed to tell which
code is thumb. After doing "set arm fallback-mode thumb" the SIGSEGV
disappears.
Extend the test-case to check the "maint info break" command before and after
the two failed attempts, to make sure that we catch the stale
"watchpoint scope" breakpoints also on x86_64-linux.
Fix this in watch_command_1 by moving creation of the "watchpoint scope"
breakpoint after the call to update_watchpoint.
Tested on x86_64-linux.
PR breakpoints/31860
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31860
When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get:
...
FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1
FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2
...
The problem is that the debug info produced by clang does not contain any
references to enumerators val1 and val2, or the corresponding enumeration
types.
Instead, the variables u1 and u2 are considered to be simply of type int:
...
<1><fb>: Abbrev Number: 2 (DW_TAG_variable)
<fc> DW_AT_name : u1
<fd> DW_AT_type : <0x106>
<101> DW_AT_external : 1
<103> DW_AT_location : (DW_OP_addrx <0>)
<1><106>: Abbrev Number: 3 (DW_TAG_base_type)
<107> DW_AT_name : int
<108> DW_AT_encoding : 5 (signed)
<109> DW_AT_byte_size : 4
<1><10a>: Abbrev Number: 2 (DW_TAG_variable)
<10b> DW_AT_name : u2
<10c> DW_AT_type : <0x106>
<110> DW_AT_external : 1
<112> DW_AT_location : (DW_OP_addrx <0x1>)
...
Fix this by checking whether val1 and val2 are present in the cooked index
before checking whether they have the correct parent.
This cannot be expressed efficiently with gdb_test_lines, so factor out
gdb_get_lines and use that instead.
The test-case still calls "maint print objfiles" twice, but the first time is
for have_index. We should probably use a gdb_caching_proc for this.
Tested on aarch64-linux.
Reported-By: Guinevere Larsen <guinevere@redhat.com>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Tested-By: Guinevere Larsen <guinevere@redhat.com>
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output.
Tested on x86_64-linux.
On aarch64-linux, with make target check-read1, I run into:
...
(gdb) info reg vector^M
...
d19 {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout)
0, u = 0, s = 0}^M
...
The problem is that while (as documented) the corresponding gdb_test_multiple
doesn't work for vector registers, it doesn't skip them either. This causes
the timeout, and it also causes the registers after a vector register not to
be found.
Fix this by using -lbl style matching.
Make which reggroups and registers are found more explicit using verbose -log,
which makes us notice that regnames with underscores are skipped, so fix that
as well.
While we're at it, this:
...
set invalid_register_re "Invalid register .*"
...
and this:
...
-re $invalid_register_re {
fail "$test (unexpected invalid register response)"
}
...
means that the prompt may or may not be consumed. Fix this by limiting the
regexp to one line, and using exp_continue.
While we're at it, improve readability of the complex regexp matching a single
register by factoring out regexps.
Tested on aarch64-linux and x86_64-linux.
This changes a few implementations of "info proc mappings" to use
ui-out tables rather than printf.
Note that NetBSD and FreeBSD also use printfs here, but since I can't
test these, I didn't update them.
Approved-By: Andrew Burgess <aburgess@redhat.com>
When running test-case gdb.base/break-interp.exp with check-read1, I run into:
...
(gdb) info files^M
...
0x00007ffff7e75980 - 0x00007ffff7e796a0 @ 0x001f1970 is .bss in /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.base/break-interp/break-interp-BINprelinkNOdebugNOFAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: symbol-less: info files (timeout)
pieNO.d/libc.so.6^M
...
The code has two adaptations to deal with the large output:
- nested gdb_test_multiple, and
- an exp_continue in the inner gdb_test_multiple.
The former seems unnecessary, and the latter doesn't trigger often enough
because of an incomplete hex number regexp, causing the timeout.
Get rid of both of these, and use -lbl instead.
Tested on x86_64-linux.
Include the value of configuration flag --enable-targets in the output
of GDB command 'show configuration' and also in the output printed for
'gdb --configuration'. This will make it easier to see how GDB was
built.
No tests added or updated as we can't really check for a specific flag
appearing or not appearing on the configuration output. But we do
print the configuration within lib/gdb.exp to check which features are
built into GDB, so if this change broke configuration printing then
plenty of tests should stop working (they don't).
Approved-By: Tom Tromey <tom@tromey.com>
The commit:
commit 6cce025114
Date: Fri Mar 3 19:03:15 2023 +0000
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Tested on aarch64-linux.
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)
...
[37] ((cooked_index_entry *) 0x38ffd280)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xef
parent: ((cooked_index_entry *) 0)
...
There are two entries, which seems to be an inefficiency, but for now let's
focus on the correctness issue.
The debug info for val1 looks like this:
...
<1><cb>: Abbrev Number: 2 (DW_TAG_namespace)
<cc> DW_AT_name : ns
<cf> DW_AT_declaration : 1
<2><d3>: Abbrev Number: 12 (DW_TAG_class_type)
<d4> DW_AT_name : A
<d6> DW_AT_declaration : 1
<3><d6>: Abbrev Number: 13 (DW_TAG_enumeration_type)
<db> DW_AT_declaration : 1
<1><dd>: Abbrev Number: 14 (DW_TAG_enumeration_type)
<e7> DW_AT_specification: <0xd6>
<2><ef>: Abbrev Number: 5 (DW_TAG_enumerator)
<f0> DW_AT_name : val1
<f4> DW_AT_const_value : 1
...
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.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
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
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
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.
[1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/
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>
Commit 68bbe11833 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/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.
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.
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.
Likewise in gdb.dap/memory.exp.
Tested on x86_64-linux.
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>
