Drop an unnecessary variable, and fix a buggy comment.
No effect on generated code.
libctf/
* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Drop unnecessary
variable.
(ctf_dedup_rwalk_output_mapping): Fix comment.
This erorr doesn't just indicate that there is no parent dictionary
(that's routine, and true of all dicts that are parents themselves)
but that a parent is *needed* but wasn't found.
include/
* ctf-api.h (_CTF_ERRORS) [ECTF_NOPARENT]: Improve error message.
ld/
* testsuite/ld-ctf/diag-parname.d: Adjust.
Commit 483546ce4f ("libctf: make ctf_serialize() actually serialize")
accidentally broke dict compression. There were two bugs:
- ctf_arc_write_one_ctf was still making its own decision about
whether to compress the dict via direct ctf_size comparison, which is
unfortunate because now that it no longer calls ctf_serialize itself,
ctf_size is always zero when it does this: it should let the writing
functions decide on the threshold, which they contain code to do which is
simply not used for lack of one trivial wrapper to write to an fd and
also provide a compression threshold
- ctf_write_mem, the function underlying all writing as of the commit
above, was calling zlib's compressBound and avoiding compression if this
returned a value larger than the input. Unfortunately compressBound does
not do a trial compression and determine whether the result is
compressible: it just adds zlib header sizes to the value passed in, so
our test would *always* have concluded that the value was incompressible!
Avoid by simply always compressing if the raw size is larger than the
threshold: zlib is quite clever enough to avoid actually compressing
if the data is incompressible.
Add a testcase for this.
libctf/
* ctf-impl.h (ctf_write_thresholded): New...
* ctf-serialize.c (ctf_write_thresholded): ... defined here,
a wrapper around...
(ctf_write_mem): ... this. Don't check compressibility.
(ctf_compress_write): Reimplement as a ctf_write_thresholded
wrapper.
(ctf_write): Likewise.
* ctf-archive.c (arc_write_one_ctf): Just call
ctf_write_thresholded rather than trying to work out whether
to compress.
* testsuite/libctf-writable/ctf-compressed.*: New test.
If you deduplicate non-root-visible types, the resulting type should still
be non-root-visible! We were promoting all such types to root-visible, and
re-demoting them only if their names collided (which might happen on
cu-mapped links if multiple compilation units with conflicting types are
fused into one child dict).
This "worked" before now, in that linking at least didn't fail (if you don't
mind having your non-root flag value destroyed if you're adding
non-root-visible types), but now that conflicting enumerators cause their
containing enums to become conflicted (enums which might have *different
names*), this caused the linker to crash when it hit two enumerators with
conflicting values.
Not testable in ld because cu-mapped links are not exposed to ld, but can be
tested via direct creation of libraries and calls to ctf_link directly.
(This also tests the ctf_dump non-root type printout, which before now
was untested.)
libctf/
* ctf-dedup.c (ctf_dedup_emit_type): Non-root-visible input types
should be emitted as non-root-visible output types.
* testsuite/libctf-writable/ctf-nonroot-linking.c: New test.
* testsuite/libctf-writable/ctf-nonroot-linking.lk: New test.
The flag test when dumping non-root-visible tyeps was doubly wrong: the
flags word is a *bitfield* containing CTF_ADD_ROOT as one possible
value, so needs | and & testing, not just ==, and CTF_ADD_NONROOT is 0,
so cannot be tested for this way: one must check for the non-presence of
CTF_ADD_ROOT.
libctf/
* ctf-dump.c (ctf_dump_format_type): Fix non-root flag test.
In commit 149ce5c263 we introduced the concept of "movable" refs,
which are refs that can be moved in batches, to let us maintain valid ref
lists even when adding refs to blocks of memory that can be realloced (which
is any type containing a vlen which can expand, like names contained within
enum or struct members). Movable refs need a backpointer to the movable
refs dynhash for this dict; since non-movable refs are very common, we tried
to save memory by having a slightly bigger struct for moveable refs with a
backpointer in it, and casting appropriately, indicating which sort of ref
we were dealing with via a flag on the atom.
Unfortunately this doesn't work reliably, because you can perfectly well
have a string ("foo", say) which has both non-movable refs (say, an external
symbol and a variable name) and movable refs (say, a structure member name)
to the same atom. Indicate which struct we're dealing with with an atom
flag and suddenly you're casting a ctf_str_atom_ref to a
ctf_str_atom_ref_movable (which is bigger) and dereferencing random memory
off the end of it and interpreting it as a backpointer to the movable refs
dynhash. This is unlikely to work well.
So bite the bullet and split refs into two separate lists, one for movable
refs, one for immovable refs. It means some annoying code duplication, but
there's not very much of it, and it means we can keep the movable refs
hashtab (which in turn means we don't have to do linear searches to find all
relevant refs when moving refs, which in turn means that
structure/union/enum member additions remain amortized O(n) time, not
O(n^2).
Callers can now purge movable and non-movable refs independently of each
other. We don't use this yet, but a use is coming.
libctf/
* ctf-impl.h (CTF_STR_ATOM_MOVABLE): Delete.
(struct ctf_str_atom) [csa_movable_refs]: New.
(struct ctf_dict): Adjust comment.
(ctf_str_purge_refs): Add MOVABLE arg.
* ctf-string.c (ctf_str_purge_movable_atom_refs): Split out of...
(ctf_str_purge_atom_refs): ... this.
(ctf_str_free_atom): Call it.
(ctf_str_purge_one_atom_refs): Likewise.
(aref_create): Adjust accordingly.
(ctf_str_move_refs): Likewise.
(ctf_str_remove_ref): Remove movable refs too, including
deleting the ref from ctf_str_movable_refs.
(ctf_str_purge_refs): Add MOVABLE arg.
(ctf_str_update_refs): Update movable refs.
(ctf_str_write_strtab): Check, and purge, movable refs.
The PARENTS arg is carefully passed down through all the layers of hash
functions and then never used for anything. (In the distant past it was
used for cycle detection, but the algorithm eventually committed doesn't
need to do cycle detection...)
The PARENTS arg is still used by ctf_dedup_emit(), but even there we can
loosen the requirements and state that you can just leave entries
corresponding to dicts with no parents at zero (which will be useful
in an upcoming commit).
libctf/
* ctf-dedup.c (ctf_dedup_hash_type): Drop PARENTS arg.
(ctf_dedup_rhash_type): Likewise.
(ctf_dedup): Likewise.
(ctf_dedup_emit_struct_members): Mention what you can do to
PARENTS entries for parent dicts.
* ctf-impl.h (ctf_dedup): Adjust accordingly.
* ctf-link.c (ctf_link_deduplicating_per_cu): Likewise.
(ctf_link_deduplicating): Likewise.
The worry that caused this to not be supported was because we don't
bother endian-flipping version-related fields before checking them.
But they're all unsigned chars anyway, and don't need any flipping at
all.
This should be supported and should already work. Enable it.
libctf/
* ctf-open.c (ctf_bufopen): Don't prohibit foreign-endian
upgrades.
When using a duplicate test name:
...
fail foo
fail foo
...
we get:
...
FAIL: $exp: foo
FAIL: $exp: foo
DUPLICATE: $exp: foo
...
But when we do:
...
fail foo
fail "foo (timeout)"
...
we get only:
...
FAIL: $exp: foo
FAIL: $exp: foo (timeout)
...
Trailing text between parentheses prefixed with a space is interpreted as
extra information, and not as part of the test name [1].
Consequently, "foo" and "foo (timeout)" do count as duplicate test names,
which should have been detected. This is PR testsuite/29772.
Fix this in CheckTestNames::_check_duplicates, such that we get:
...
FAIL: $exp: foo
FAIL: $exp: foo (timeout)
DUPLICATE: $exp: foo (timeout)
...
[ One note on the implementation: I used the regexp { \([^()]*\)$}. I don't
know whether that covers all required cases, due to the fact that those are
not unambiguousely specified. It might be possible to reverse-engineer that
information by reading or running the "regression analysis tools" mentioned on
the wiki page [1], but I haven't been able to. Regardless, the current regexp
covers a large amount of cases, which IMO should be sufficient to be
acceptable. ]
Doing so shows many new duplicates in the testsuite.
A significant number of those is due to using a message which is a copy of the
command:
...
gdb_test "print (1)"
...
Fix this by handling those cases using test names "gdb-command<print (1)>" and
"gdb-command<print (2)>.
Fix the remaining duplicates manually (split off as follow-up patch for
readability of this patch).
Tested on x86_64-linux and aarch64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29772
[1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages
I tried to reproduce a problem in test-case gdb.python/py-disasm.exp on a
s390x machine, but when running with target board unix/-m31 I saw that the
required libraries were missing, so I couldn't generate an executable.
However, I realized that I did have an object file, and the test-case should
mostly also work with an object file.
I've renamed gdb.python/py-disasm.exp to gdb.python/py-disasm.exp.tcl and
included it from two new minimal test-case wrappers:
- gdb.python/py-disasm-exec.exp, and
- gdb.python/py-disasm-obj.exp
where the former uses an executable as before, and the latter uses an object
file.
Using an object file required changing the info.read_memory calls in
gdb.python/py-disasm.py:
...
- info.read_memory(1, -info.address + 2)
+ info.read_memory(1, -info.address - 1)
...
because reading from address 2 succeeds. Using address -1 instead does
generate the expected gdb.MemoryError.
Tested on x86_64-linux.
When running test-case gdb.fortran/intrinsics.exp on arm-linux, I get:
...
(gdb) p cmplx (4,4,16)^M
/home/linux/gdb/src/gdb/f-lang.c:1002: internal-error: eval_op_f_cmplx: \
Assertion `kind_arg->code () == TYPE_CODE_COMPLEX' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
----- Backtrace -----^M
FAIL: gdb.fortran/intrinsics.exp: p cmplx (4,4,16) (GDB internal error)
...
The problem is that 16-byte floats are unsupported:
...
$ gfortran test.f90
test.f90:2:17:
2 | REAL(kind=16) :: foo = 1
| 1
Error: Kind 16 not supported for type REAL at (1)
...
and consequently we end up with a builtin_real_s16 and builtin_complex_s16 with
code TYPE_CODE_ERROR.
Fix this by bailing out asap when encountering such a type.
Without this patch we're able to do the rather useless:
...
(gdb) ptype real*16
type = real*16
(gdb) ptype real_16
type = real*16
...
but with this patch we get:
...
(gdb) ptype real*16
unsupported kind 16 for type real*4
(gdb) ptype real_16
unsupported type real*16
...
Tested on arm-linux.
PR fortran/30537
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30537
This had been badly inserted between md_assemble() and its helpers
anyway. Follow what was done for Arm64 and move the code to its own
file, #include-d as appropriate.
Running the testsuite for an x86_64-w64-mingw32 target using the
Ubuntu package gcc-mingw-w64-x86-64 version 13.2.0-6ubuntu1+26.1
results in a number of messages:
ERROR: can't decipher gcc version number, fix the framework!
Someone in their wisdom decided this compiler should advertise itself
with a version of 13-win32, breaking the ld testsuite version checks.
(It is also configured using --with-as=/usr/bin/x86_64-w64-mingw32-as
--with-ld=/usr/bin/x86_64-w64-mingw32-ld which renders the -B flag
inoperative for testing the newly built gas and ld. You'd need to
install binutils over the top of the Ubuntu versions before testing, a
rather unsatisfactory process.)
* testsuite/lib/ld-lib.exp (at_least_gcc_version): Use
preprocessor test of __GNUC__ and __GNUC_MINOR__ rather than
output of gcc --version. Correct removal of -Wl options.
When running test-case gdb.ada/mi_var_access.exp on arm-linux (debian trixie),
I run into:
...
Expecting: ^(-var-create A_String_Access \* A_String_Access[
]+)?((\^done,name="A_String_Access",numchild="[0-9]+",.*|\^error,msg="Value out of range.".*)[
]+[(]gdb[)]
[ ]*)
-var-create A_String_Access * A_String_Access
^error,msg="Cannot access memory at address 0x4"
(gdb)
FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output)
...
This is similar to the problem fixed by commit c5a72a8d1c ("[gdb/testsuite]
Fix regexp in gdb.ada/mi_var_access.exp").
The problem in both cases is that we're printing an uninitialized variable,
and consequently we can run into various error messages during printing.
Fix this as in the other commit, by accepting the error message.
Tested on arm-linux.
Since commit b1da98a746 ("gdb: remove use of alloca in
new_macro_definition"), if cached_argv is empty, we call macro_bcache
with a nullptr data. This ends up caught by UBSan deep down in the
bcache code:
$ ./gdb -nx -q --data-directory=data-directory /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp -readnow
Reading symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp...
Expanding full symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp...
/home/smarchi/src/binutils-gdb/gdb/bcache.c:195:12: runtime error: null pointer passed as argument 2, which is declared to never be null
The backtrace:
#1 0x00007ffff619a05d in __ubsan::__ubsan_handle_nonnull_arg_abort (Data=<optimized out>) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:750
#2 0x000055556337fba2 in gdb::bcache::insert (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.c:195
#3 0x0000555564b49222 in gdb::bcache::insert<char const*, void> (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.h:158
#4 0x0000555564b481fa in macro_bcache<char const*> (t=0x62100007ae70, addr=0x0, len=0) at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:117
#5 0x0000555564b42b4a in new_macro_definition (t=0x62100007ae70, kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:573
#6 0x0000555564b44674 in macro_define_internal (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:777
#7 0x0000555564b44ae2 in macro_define_function (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:816
#8 0x0000555563f62fc8 in parse_macro_definition (file=0x6210000ab9e0, line=469, body=0x62a00003af2a "__va_arg_pack() __builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:203
This can be reproduced by running gdb.base/macscp.exp. Avoid calling
macro_bcache if the macro doesn't have any arguments.
Change-Id: I33b5a7c3b3a93d5adba98983fcaae9c8522c383d
strchr is redefined as a macro in /usr/include/bits/string.h on CentOS 6/7.
In this case, we may not use our CALL_UTIL macro for strchr.
Use __collector_strchr instead of "CALL_UTIL (strchr)".
gprofng/ChangeLog
2024-07-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR 32018
* libcollector/hwprofile.c (open_experiment): Use __collector_strchr.
Add a test-case gdb.dwarf2/macro-complaints.exp, that checks complaints for the
.debug_macro section.
For one malformed macro definition, I get two identical complaints:
...
During symbol reading: macro debug info contains a malformed macro definition:^M
`M1_11_MALFORMED(ARG'^M
During symbol reading: macro debug info contains a malformed macro definition:^M
`M1_11_MALFORMED(ARG'^M
...
Fix this by bailing out after the first one.
Tested on aarch64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Use std::vector<std::string> when defining macros, to avoid the manual
memory management.
With the use of std::vector, the separate `int argc` parameter is no
longer needed, we can use the size of the vector instead. However, for
some functions, this parameter had a dual function. For object-like
macros, it was interpreted as a `macro_special_kind` enum. For these
functions, remove `argc`, but add a new `special_kind` parameter.
Change-Id: Ice76a6863dfe598335e3b8d5d077513e50975cc5
Approved-By: Tom de Vries <tdevries@suse.de>
When building the GDB info manual I see this warning:
gdb.texinfo:41447: warning: @anchor should not appear on @item line
And indeed line 41447 looks like this:
@item @anchor{maint info breakpoints}maint info breakpoints
I propose moving the @anchor{...} part to the previous line which
silences the warning.
Approved-By: Eli Zaretskii <eliz@gnu.org>
It also tests the gcore script being run without its accessible
terminal.
This test was written by Jan Kratochvil a long time ago. I modernized
the test making it use various procs from lib/gdb.exp, reorganizing it
and added some comments.
Modify the gcore script to make it possible to pass the --data-directory to
it. This prevents a lot of these warnings:
Python Exception <class 'AttributeError'>: module 'gdb' has no attribute
'_handle_missing_debuginfo'
Tested by using make check-all-boards.
Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
When building gdb with -g0 and running test-case gdb.gdb/index-file.exp, we
run into:
...
(gdb) save gdb-index index_1^M
Error while writing index for `xgdb': No debugging symbols^M
(gdb) FAIL: gdb.gdb/index-file.exp: create gdb-index file
...
Fix this by instead emitting an unsupported, and bailing out.
Tested on aarch64-linux.
When running test-case gdb.threads/leader-exit-attach.exp with target board
native-extended-gdbserver I run into:
...
(gdb) KFAIL: $exp: attach (PRMS: gdb/31555)
print $_inferior_thread_count^M
$1 = 0^M
(gdb) KPASS: $exp: get valueof "$_inferior_thread_count" (PRMS server/31554)
...
The PR mentioned in the KPASS, PR31554 was fixed by commit f1fc8dc2dc
("Fix "attach" failure handling with GDBserver"), and consequently the PR is
closed.
Fix this by removing the corresponding kfail.
Tested on x86_64-linux.
With test-case gdb.threads/leader-exit-attach.exp and check-read1, I run into:
...
(gdb) attach 18591^M
Attaching to program: leader-exit-attach, process 18591^M
warning: process 18591 is a zombie - the process has already terminatedKFAIL: $exp: attach (PRMS: gdb/31555)
^M
ptrace: Operation not permitted.^M
(gdb) FAIL: $exp: get valueof "$_inferior_thread_count"
...
The problem is that the gdb_test_multiple in the test-case doesn't consume the
prompt in all clauses:
...
gdb_test_multiple "attach $testpid" "attach" {
-re "Attaching to process $testpid failed.*" {
# GNU/Linux gdbserver. Linux ptrace does not let you attach
# to zombie threads.
setup_kfail "gdb/31555" *-*-linux*
fail $gdb_test_name
}
-re "warning: process $testpid is a zombie - the process has already terminated.*" {
# Native GNU/Linux. Linux ptrace does not let you attach to
# zombie threads.
setup_kfail "gdb/31555" *-*-linux*
fail $gdb_test_name
}
-re "Attaching to program: $escapedbinfile, process $testpid.*$gdb_prompt $" {
pass $gdb_test_name
set attached 1
}
}
...
Fix this by using -wrap in the first two clauses.
While we're at it, also use -wrap in the third clause.
Tested on x86_64-linux.
This brings us down to just these fails for the set of targets I
usually test when making testsuite changes.
aarch64-pe +FAIL: ld-pe/symbols-ordinals-hints-imports-ld
arm-pe +FAIL: ld-pe/symbols-ordinals-hints-exports-dlltool
arm-pe +FAIL: ld-pe/symbols-ordinals-hints-imports-dlltool
The aarch64 one is likely due to the target missing support somewhere.
It is fairly new, I haven't investigated. The arm-pe fails are due to
arm-pe being a target that adds underscores to symbol names (see
config.bfd) whereas dlltool thinks it does not (see
dlltool.c:asm_prefix). arm-wince-pe on the other hand doesn't add
underscores. I would guess the right fix for dlltool is to get this
symbol info from bfd using bfd_get_target_info.
Note I'm not very happy about the creative use of ld_after_inputfile
in symbols-ordinals-hints-imports-ld.d, which is likely to break with
some future run_dump_test change.
Fixing the segfault is easy with this bandaid, but further work is
needed to teach dwp about DW_AT_dwo_name and dwo id in the cu header.
At the moment dwp only handles DW_AT_GNU_dwo_name and DW_AT_GNU_dwo_id.
PR 32032
* dwp.cc (Dwp_output_file::finalize): Return immediately on
no output file.
After a recent patch review I asked myself why can_spawn_for_attach
exists. This proc currently does some checks, and then calls
can_spawn_for_attach_1 which is an actual caching proc.
The answer is that can_spawn_for_attach exists in order to call
gdb_exit the first time can_spawn_for_attach is called within any test
script.
The reason this is useful is that can_spawn_for_attach_1 calls
gdb_exit. If the user calls can_spawn_for_attach_1 directly then a
problem might exist. Imagine a test written like this:
gdb_start
if { [can_spawn_for_attach_1] } {
... do stuff that assumes GDB is running ...
}
If this test is NOT the first test run, and if an earlier test calls
can_spawn_for_attach_1, then when the above test is run the
can_spawn_for_attach_1 call will return the cached value and gdb_exit
will not be called.
But, if the above test IS the first test run then
can_spawn_for_attach_1 will not return the cached value, but will
instead compute the cached value, a process that ends up calling
gdb_exit. When can_spawn_for_attach_1 returns GDB will have exited
and the test might fail if it is written assuming that GDB is
running.
So can_spawn_for_attach was added which ensures that we _always_ call
gdb_exit the first time can_spawn_for_attach is called within a single
test script, this ensures that in the above case, even if the above is
not the first test script run, gdb_exit will still be called. This
ensures consistent behaviour and avoids some hidden bugs in the
testsuite.
The split between can_spawn_for_attach and can_spawn_for_attach_1 was
introduced in this commit:
commit 147fe7f9fb
Date: Mon May 6 14:27:09 2024 +0200
[gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach
However, I observe that can_spawn_for_attach is not the only caching
proc that calls gdb_exit. Why does can_spawn_for_attach get special
treatment when surely the same issue exists for any other caching proc
that calls gdb_exit?
I think a better solution is to move the logic from
can_spawn_for_attach into cache.exp and generalise it so that it
applies to all caching procs.
This commit does this by:
1. When the underlying caching proc is executed we track calls to
gdb_exit. If a caching proc calls gdb_exit then this information
is stored in gdb_data_cache (using a ',exit' suffix), and also
written to the cache file if appropriate.
2. When a cached value is returned from gdb_do_cache, if the
underlying proc would have called gdb_exit, and if this is the
first use of the caching proc in this test script, then we call
gdb_exit.
When storing the ',exit' value into the on-disk cache file, the flag
value is stored on a second line. Currently every cached value only
occupies a single line, and a check is added to ensure this remains
true in the future.
To track calls to gdb_exit I eventually settled on using TCL's trace
mechanism. We already make use of this in lib/gdb.exp so I figure
this is OK to use. This should be fine, so long as non of the caching
procs use 'with_override' to replace gdb_exit, or do any other proc
replacement to change gdb_exit, however, I think that is pretty
unlikely.
One issue did come up in testing, a FAIL in gdb.base/break-interp.exp,
prior to this commit can_spawn_for_attach would call gdb_exit before
calling the underlying caching proc. After this call we call gdb_exit
after calling the caching proc.
The underlying caching proc relies on gdb_exit having been called. To
resolve this issue I just added a call to gdb_exit into
can_spawn_for_attach.
With this done can_spawn_for_attach_1 can be renamed to
can_spawn_for_attach, and the existing can_spawn_for_attach can be
deleted.
In the next commit I want to add more information to
gdb_data_cache (see lib/cache.exp). Specifically I want to track if
the underlying function of a caching proc calls gdb_exit or not.
Currently gdb_data_cache is an associative array, the keys of which
are the name of the caching proc.
In this commit I add a ',value' suffix to the gdb_data_cache keys. In
the next commit I'll add additional entries with a different suffix.
There should be no noticable changes after this commit, this is just a
restructuring.
On an aarch64-linux system with 32-bit userland running in a chroot, and using
target board unix/mthumb I get:
...
(gdb) hbreak hbreak.c:27^M
Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M
(gdb) PASS: gdb.base/hbreak.exp: hbreak
continue^M
Continuing.^M
Unexpected error setting breakpoint: Invalid argument.^M
(gdb) XFAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak
...
due to this call in arm_linux_nat_target::low_prepare_to_resume:
...
if (ptrace (PTRACE_SETHBPREGS, pid,
(PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0)
perror_with_name (_("Unexpected error setting breakpoint"));
...
This problem does not happen if instead we use a 4-byte aligned address.
This may or may not be a kernel bug.
Work around this by first using an inoffensive address bpts[i].address & ~0x7.
Likewise in arm_target::low_prepare_to_resume, which fixes the same fail on
target board native-gdbserver/mthumb.
While we're at it:
- use arm_hwbp_control_is_initialized in
arm_linux_nat_target::low_prepare_to_resume,
- handle the !arm_hwbp_control_is_initialized case explicitly,
- add missing '_()' in arm_target::low_prepare_to_resume,
- make error messages identical between arm_target::low_prepare_to_resume and
arm_linux_nat_target::low_prepare_to_resume,
- factor out sethbpregs_hwbp_address and sethbpregs_hwbp_control to
make the implementation more readable.
Remove the tentative xfail added in d0af16d5a1 ("[gdb/testsuite] Add xfail in
gdb.base/hbreak.exp") by simply reverting the commit.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Add the MT ASE instruction operand types and encodings to the microMIPS
opcode table and enable the assembly of these instructions in GAS from
MIPSr2 onwards. Update the binutils and GAS testsuites accordingly.
References:
"MIPS Architecture for Programmers, Volume IV-f: The MIPS MT Module for
the microMIPS32 Architecture", MIPS Technologies, Inc., Document Number:
MD00768, Revision 1.12, July 16, 2013
Co-Authored-By: Maciej W. Rozycki <macro@redhat.com>
It was pointed out in this message:
https://inbox.sourceware.org/gdb-patches/5d7a514b-5dad-446f-a021-444ea88ecf07@redhat.com
That the test gdb.base/build-id-seqno.exp I added recently was FAILing
when using Clang as the compiler.
The problem was that I had failed to add 'build-id' as a compile
option in the call to build_executable within the test script. For
GCC this is fine as build-ids are included by default. For Clang
though this meant the build-id was not included and the test would
fail.
So I added build-id to the compiler options.... and the test still
didn't pass! Now the test fails to compile and I see this error from
the compiler:
gdb compile failed, clang-15: warning: -Wl,--build-id: 'linker' \
input unused [-Wunused-command-line-argument]
It turns out that the build-id compile option causes our gdb.exp to
add the '-Wl,--build-id' option into the compiler flags, which means
its used when building the object file AND during the final link.
However this option is unnecessary when creating the object file and
Clang warns about this, which causes the build to fail.
The solution is to change gdb.exp, instead of adding the build-id
flags like this:
lappend new_options "additional_flags=-Wl,--build-id"
we should instead add them like:
lappend new_options "ldflags=-Wl,--build-id"
Now the flag is only appended during the link phase and Clang is
happy. The gdb.base/build-id-seqno.exp test now passes with Clang.
The same problem (adding to additional_flags instead of ldflags)
exists for the no-build-id compile option, so I've fixed that too.
While investigating this I also spotted two test scripts,
gdb.base/index-cache.exp and gdb.dwarf2/per-bfd-sharing.exp which were
setting ldflag directly rather than using the build-id compile option
so I've updated these two tests to use the compile option which I
think is neater.
I've checked that all these tests still pass with both GCC and Clang.
There should be no changes in what is actually tested after this
commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Instead re-use code handling LEX_IS_TWOCHAR_COMMENT_1ST, thus ensuring
that we wouldn't get bogus state transitions: For example, when we're in
states 0 or 1, a comment should be no different from whitespace
encountered in those states. Plus for e.g. x86 this results in such
comments now truly being converted to a blank, as mandated by
documentation. Both aspects apparently were a result of blindly (and
wrongly) moving to state 3 _before_ consuming the "ungot" blank.
Also amend a related comment elsewhere.
In the new testcase the .irp is to make visible in the listing all the
whitespace that the scrubber inserts / leaves in place.
... and prediction suffix comma. Other than documented /**/ comments
currently aren't really converted to a single space, at least not for
x86 in its most common configurations. That'll be fixed subsequently, at
which point blanks may appear where so far none were expected.
Furthermore not permitting blanks around these separators wasn't quite
logical anyway - such constructs are composite ones, and hence
components ought to have been permitted to be separated by whitespace
from the very beginning. Furthermore note how, due to the scrubber being
overly aggressive in removing whitespace, some similar construct with a
prefix were already accepted.
Note how certain other checks in parse_insn() can be simplified as a
result.
While there for the prediction suffix also make checks case-insensitive
and check for a proper trailing separator.
It's wrong to have ${srcdir} in run_dump_test "source:" lines, as
run_dump_test adds $srcdir/$subdir/ to the line passed to the shell
except when the source path starts with "./". The tests work
currently because the shell expands ${srcdir} to an empty string.
PR 31728
* testsuite/ld-i386/code16.d: Correct "source:".
* testsuite/ld-x86-64/code16.d: Likewise.
* testsuite/ld-x86-64/rela.d: Likewise.
This corrects objdump -d -m armv8.1-m.main output for a testcase found
by oss-fuzz, .inst 0xee2fee79, which hits an assertion.
Obviously the switch case constants should be binary, not hex.
Correcting that is enough to cure this assertion, but I don't see any
point in singling out the invalid case 0b10. In fact, it is just plain
wrong to print "undefined instruction: size equals zero undefined
instruction: size equals two".
I also don't see the need for defensive programming here as is done
elsewhere in checking that "value" is in range before indexing
mve_vec_sizename. There is exactly one MVE_VSHLL_T2 entry in
mve_opcodes. It is easy to verify that "value" is only two bits.
