Since only the abandoned privileged spec v1.9.1 will have conflict csrs, to
keep the compatible we still report warnings when linking privileged spec
v1.9.1 objects with others. But don't report warnings for other compatible
cases because it is actually a bit noisy and useless...
bfd/
* elfnn-riscv.c (riscv_merge_attributes): Only report warnings when
linking the abandoned privileged spec v1.9.1 object with others.
ld/
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Removed.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Removed.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Removed.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Removed.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Removed.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Removed.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
There is no overflow check for the relaxation of pcalau12i+ld.d =>
pcalau12i+addi.d. For instruction sequences that can be relaxed,
they are directly relaxed to pcalau12i+addi.d. However, when the
relative distance between the symbol and the pc exceeds the 32-bit
range, the symbol value cannot be obtained correctly.
Adds an overflow check for the relaxation of pcalau12i+ld.d.
If it is found that the relaxation will overflow, it will not
be relaxed.
The Intel (R) linear address masking (LAM) feature modifies the checking
applied to 64-bit linear addresses. With this so-called "modified
canonicality check" the processor masks the metadata bits in a pointer
before using it as a linear address. LAM supports two different modes that
differ regarding which pointer bits are masked and can be used for
metadata: LAM 48 resulting in a LAM width of 15 and LAM 57 resulting in a
LAM width of 6.
This patch adjusts watchpoint addresses based on the currently enabled
LAM mode using the untag mask provided in the /proc/<pid>/status file.
As LAM can be enabled at runtime or as the configuration may change
when entering an enclave, GDB checks enablement state each time a watchpoint
is updated.
In contrast to the patch implemented for ARM's Top Byte Ignore "Clear
non-significant bits of address on memory access", it is not necessary to
adjust addresses before they are passed to the target layer cache, as
for LAM tagged pointers are supported by the system call to read memory.
Additionally, LAM applies only to addresses used for data accesses.
Thus, it is sufficient to mask addresses used for watchpoints.
The following examples are based on a LAM57 enabled program.
Before this patch tagged pointers were not supported for watchpoints:
~~~
(gdb) print pi_tagged
$2 = (int *) 0x10007ffffffffe004
(gdb) watch *pi_tagged
Hardware watchpoint 2: *pi_tagged
(gdb) c
Continuing.
Couldn't write debug register: Invalid argument.
~~~~
Once LAM 48 or LAM 57 is enabled for the current program, GDB can now
specify watchpoints for tagged addresses with LAM width 15 or 6,
respectively.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
The gdbarch function gdbarch_remove_non_address_bits adjusts addresses to
enable debugging of programs with tagged pointers on Linux, for instance for
ARM's feature top byte ignore (TBI).
Once the function is implemented for an architecture, it adjusts addresses for
memory access, breakpoints and watchpoints.
Linear address masking (LAM) is Intel's (R) implementation of tagged
pointer support. It requires certain adaptions to GDB's tagged pointer
support due to the following:
- LAM supports address tagging for data accesses only. Thus, specifying
breakpoints on tagged addresses is not a valid use case.
- In contrast to the implementation for ARM's TBI, the Linux kernel supports
tagged pointers for memory access.
This patch makes GDB's tagged pointer support configurable such that it is
possible to enable the address adjustment for a specific feature only (e.g
memory access, breakpoints or watchpoints). This way, one can make sure
that addresses are only adjusted when necessary. In case of LAM, this
avoids unnecessary parsing of the /proc/<pid>/status file to get the
untag mask.
Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
(AArch64) Tested-By: Luis Machado <luis.machado@arm.com>
Approved-By: Luis Machado <luis.machado@arm.com>
Map7 already has dual purpose for USER-MSR (and is to gain more for
MSR-IMM), while Map5 is about to gain VEX uses for AMX extensions. Drop
the not really meaningful infixes and (in the opcode table) prefixes,
retaining merely EVexMap4 for encoding EVex128 at the same time.
Much like AVX512-{4FMAPS,4VNNIW} have a constraint on their register
source, there's a constraint (need to be even) on the destination
register here.
Adjust "good" test cases accordingly, and add a new test case to check
the warning.
Since commit 5cb0406bb6 ("[gdb/contrib] Handle capitalized words in
spellcheck.sh"), spellcheck.sh uses '${pat@u}' which is available starting
bash 5.1, and consequently the script breaks with bash 4.4.
Fix this by checking for the bash version, and using an alternative
implementation for bash < 5.1.
Tested on x86_64-linux.
Specifying the compiler flag `-Wl,--package-metadata=<JSON>` will not
work in case the JSON contains a comma, because compiler drivers eat
commas. Example:
```
$ echo "void main() { }" > test.c
$ gcc '-Wl,--package-metadata={"type":"deb","os":"ubuntu"}' test.c
/usr/bin/ld: cannot find "os":"ubuntu"}: No such file or directory
collect2: error: ld returned 1 exit status
```
The quotation marks in the JSON value do not work well with shell nor
make. Specifying the `--package-metadata` linker flag in a `LDFLAGS`
environment variable might loose its quotation marks when it hits the
final compiler call.
So support percent-encoded and %[string] encoded JSON data in the
`--package-metadata` linker flag. Percent-encoding is used because it is
a standard, simple to implement, and does take too many additional
characters. %[string] encoding is supported for having a more readable
encoding.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32003
Bug-Ubutru: https://bugs.launchpad.net/bugs/2071468
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
Invoking this repeatedly in an inner loop is not only inefficient, but
may lead to inconsistencies in e.g. the listings that the original
comment author cared about. (Accept potential inconsistencies across
distinct sections though, to cover all invocations of the function.)
It's not overly useful without it, but the spec doesn't name any
dependency between the two. People may want to use it for purely
informational purposes, for example. Adjust, in particular, entity size
processing to be engaged if either flag is set, as mandated by the spec.
bfd/merge.c puts in quite some effort to track mergable sections. That's
all wasted for sections which don't have contents, as for them
_bfd_write_merged_section() will never be called.
With the combination not having any useful effect, also warn about this
in gas.
This won't have any useful effect, so is at best marginally less bogus
than a negative value.
The change actually points out a flawed (for Arm) testcase: @ is a
comment character there.
C23 removes support for unprototyped functions. Fix function pointer types
accordingly.
This does not fix all instances, there's a few left as I commented on in
PR32374 (e.g. setitimer which I have a local workaround for but it involves
a glibc implementation detail; the Linaro precommit CI tester pointed that
out too, so dropped that).
ChangeLog:
PR gprofng/32374
* libcollector/collector.c (collector_sample): Fix prototype.
* libcollector/envmgmt.c (putenv): Ditto.
(_putenv): Ditto.
(__collector_putenv): Ditto.
(setenv): Ditto.
(_setenv): Ditto.
(__collector_setenv): Ditto.
(unsetenv): Ditto.
(_unsetenv): Ditto.
(__collector_unsetenv): Ditto.
* libcollector/jprofile.c (open_experiment): Ditto.
(__collector_jprofile_enable_synctrace): Ditto.
(jprof_find_asyncgetcalltrace): Ditto.
* libcollector/libcol_util.c (__collector_util_init): Ditto.
(ARCH): Ditto.
* libcollector/mmaptrace.c (collector_func_load): Ditto.
(collector_func_unload): Ditto.
* libcollector/unwind.c (__collector_ext_unwind_init): Ditto.
* src/collector_module.h: Ditto.
GCC trunk now defaults to -std=gnu23. We return false in a few places
which can't work when true/false are a proper type (_Bool). Return NULL
where appropriate instead of false. All callers handle this appropriately.
ChangeLog:
PR ld/32372
* pdb.c (add_stream): Return NULL.
GCC trunk now defaults to -std=gnu23. We return false in a few places
which can't work when true/false are a proper type (_Bool). Return NULL
where appropriate instead of false. All callers handle this appropriately.
ChangeLog:
PR ld/32372
* prdbg.c (visibility_name): Return NULL.
static_assert is declared in C23 so we can't reuse that identifier:
* Define our own static_assert conditionally;
* Rename "static assert" hacks to _N as we do already in some places
to avoid a conflict.
ChangeLog:
PR ld/32372
* i386-gen.c (static_assert): Define conditionally.
* mips-formats.h (MAPPED_INT): Rename identifier.
(MAPPED_REG): Rename identifier.
(OPTIONAL_MAPPED_REG): Rename identifier.
* s390-opc.c (static_assert): Define conditionally.
GCC trunk now defaults to -std=gnu23. We return false in a few places
which can't work when true/false are a proper type (_Bool). Return NULL
where appropriate instead of false. All callers handle this appropriately.
ChangeLog:
PR ld/32372
* elf32-ppc.c (ppc_elf_tls_setup): Return NULL.
* elf32-xtensa.c (translate_reloc_bfd_fix): Ditto.
(translate_reloc): Ditto.
* elf64-ppc.c (update_local_sym_info): Ditto.
* mach-o.c (bfd_mach_o_lookup_uuid_command): Ditto.
* xsym.c (bfd_sym_read_name_table): Ditto.
Since BND PLT has been deprecated and the same IBT PLT is used for both
x86-64 and x32, always check IBT PLT before BND PLT when synthesizing
PLT symtab.
* elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Always check
elf_x86_64_lazy_ibt_plt and elf_x86_64_non_lazy_ibt_plt first.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
From the commit 667ed4b14d onward, instead
of normal name GDB looks for the "jit_descriptor" linkage name in the JIT
code initialization. Without this change, the function
"lookup_minimal_symbol_linkage", only matches the non-static data. So in
case jit_debugger is static type then setting up breakpoint in the JIT code
fails. Issue is seen for the intel compilers, where jit_debug_descriptor has
static type i.e. "mst_file_data". Hence lookup_minimal_symbol_linkage returns
nullptr for it. So, in this case breakpoint does not hit in the JIT code.
To resolve this, the commit introduces a new boolean argument to the
lookup_minimal_symbol_linkage function. This argument allows the function to
also match mst_file_data and mst_file_bss types when set to true. The
function is called with this new argument set to true only from JIT code
initialization handling, ensuring that the current behavior remains unchanged
for other cases. Because handling of static types of data symbols for all cases
result in regression for "gdb.base/print-file-var.exp" test.
Example of minsym for the JIT code emitted by the intel compilers where
lookup_minimal_symbol_linkage fails without this change because jit_debugger
type is "mst_file_data".
(top-gdb) p *msymbol
$1 = {<general_symbol_info> =
{m_name = 0x7fffcc77dc95 "__jit_debug_descriptor",
m_value = {ivalue = 84325936, block = 0x506b630,
bytes = 0x506b630 <error: Cannot access memory at address 0x506b630>,
address = 0x506b630, unrel_addr = (unknown: 0x506b630),
common_block = 0x506b630, chain = 0x506b630},
language_specific = {obstack = 0x0, demangled_name = 0x0},
m_language = language_unknown, ada_mangled = 0, m_section = 29},
m_size = 24, filename = 0x55555a751b70 "JITLoaderGDB.cpp",
m_type = mst_file_data, created_by_gdb = 0,
m_target_flag_1 = 0, m_target_flag_2 = 0, m_has_size = 1,
name_set = 1, hash_next = 0x55555b86e4f0, demangled_hash_next = 0x0}
Updated the test "jit-elf-so.exp" to test the static type of jit_descriptor
object.
Approved-By: Tom Tromey <tom@tromey.com>
Consider the following test-case:
...
$ cat test.c
int main (void) { return 0; }
$ clang -g -gsplit-dwarf test.c -o test
$ llvm-dwp -e test -o test.dwp
...
This runs into a segmentation fault:
...
$ gdb -q -batch test
Fatal signal: Segmentation fault
...
The segmentation fault happens because in read_dwo_str_index this line sets p
to nullptr:
...
const gdb_byte *p = reader->dwo_file->sections.str_offsets.buffer;
...
while the following code expects it to point to some data.
The section we're trying to read is:
...
(gdb) p reader->dwo_file->sections.str_offsets
$4 = {s = {section = 0xffffcc00a9d0, containing_section = 0xffffcc00a9d0},
buffer = 0x0, size = 28, virtual_offset = 0, readin = false, is_virtual = true}
...
At first glance, the section is not readin, but actually it is.
This is a virtual section, meaning part of a containing section:
...
(gdb) p *reader->dwo_file->sections.str_offsets.s.containing_section
$8 = {s = {section = 0xffffcc00cde8, containing_section = 0xffffcc00cde8},
buffer = 0xffffcc009650 "\030", size = 28, virtual_offset = 0, readin = true,
is_virtual = false}
...
which is readin.
Fix this in create_dwp_v2_or_v5_section by initializing the buffer of the
virtual section using the buffer of the containing section:
...
result.buffer = section->buffer + offset;
...
Unfortunately it's difficult to write a test-case for this. We'll have to
teach the dwarf assembler to generate dwp files.
Tested on aarch64-linux.
This is a partial fix for PR symtab/31497.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31497
I noticed the gdb.LazyString documentation did not mention how to
create one. Then, while adding this, I found a couple other ways that
this documentation could be clarified.
Approved-By: Eli Zaretskii <eliz@gnu.org>
It was pointed out that the recently added gdb.opt/inline-entry.exp
test would fail when run using gcc 7 and earlier, on an x86-64 target:
https://inbox.sourceware.org/gdb-patches/9fe35ea1-d99b-444d-bd1b-e3a1f108dd77@suse.de
Bernd Edlinger points out that, for gcc, the test relies on the
-gstatement-frontiers work which was added in gcc 8.x:
https://inbox.sourceware.org/gdb-patches/DU2PR08MB10263357597688D9D66EA745CE4242@DU2PR08MB10263.eurprd08.prod.outlook.com
For gcc 7.x and older, without the -gstatement-frontiers work, the
compiler uses DW_AT_entry_pc differently, which leads to a poorer
debug experience.
Here is the interesting source line from inline-entry.c:
if ((global && bar (1)) || bar (2))
And here's some of the relevant disassembly output:
Dump of assembler code for function main:
0x401020 <+0>: mov 0x3006(%rip),%eax (1)
0x401026 <+6>: test %eax,%eax (2)
0x401028 <+8>: mov 0x2ffe(%rip),%eax (3)
0x40102e <+14>: je 0x401038 <main+24> (4)
0x401030 <+16>: sub $0x1,%eax (5)
0x401033 <+19>: jne 0x40103d <main+29> (6)
Lines (1), (2), and (4) represent the check of 'global'. However,
line (3) is actually the first instruction for 'bar' which has been
inlined. Lines (5) and (6) are also part of the first inlined 'bar'
function.
If the check of 'global' returns false then the first call to 'bar'
should never happen, this is accomplished by the branch at (4) being
taken.
For gcc 8+, gcc generates a DW_AT_entry_pc with the value 0x401030,
this is where GDB places a breakpoint for 'bar', and this address is
after the branch at line (4), and so, if the call to 'bar' never
happens, the breakpoint is never hit.
For gcc 7 and older, gcc generates a DW_AT_entry_pc with the value
0x401028, which is the first address associated with the inline 'bar'
function. Unfortunately, this address is also before the check of
'global' has completed, this means that GDB hits the 'bar' breakpoint
before the inferior has decided if 'bar' should actually be called or
not.
I don't think there's really much GDB can do in the older gcc
versions, we are placing the breakpoint at the entry point, and this
is within bar. Given that this test does really depend on the newer
gcc behaviour, I think the only sensible solution is to skip this test
when an older version of gcc is being used.
I've incorporated the check for -gstatement-frontiers support that
Bernd suggested and now the test will be skipped for older versions of
GCC.
Approved-By: Tom de Vries <tdevries@suse.de>
As with the previous two commits, this commit fixes a location where
we called PyObject_IsTrue without including an error check, this time
in bppy_init.
The 'qualified' argument is supposed to be a bool, the docs say:
The optional QUALIFIED argument is a boolean that allows
interpreting the function passed in 'spec' as a fully-qualified
name. It is equivalent to 'break''s '-qualified' flag (*note
Linespec Locations:: and *note Explicit Locations::).
It's not totally clear that the only valid values are True or False,
but I'm choosing to interpret the docs that way, and so I've added a
PyBool_Type check during argument parsing. Now, if a non-bool is
passed the user will get a TypeError during argument parsing. I've
added a test to cover this case.
This is a potentially breaking change to the Python API, but hopefully
this will not impact too many people. I've added a NEWS entry to
highlight this change.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Like the previous commit, I discovered that in micmdpy_set_installed
we were calling PyObject_IsTrue, but not checking for a possible error
value being returned.
The micmdpy_set_installed function implements the
gdb.MICommand.installed attribute, and the documentation indicates that
this attribute should only be assigned a bool:
This attribute is read-write, setting this attribute to 'False'
will uninstall the command, removing it from the set of available
commands. Setting this attribute to 'True' will install the
command for use.
So I propose that instead of using PyObject_IsTrue we use
PyBool_Check, and if the new value fails this check we raise an
error. We can then compare the new value to Py_True directly instead
of calling PyObject_IsTrue.
This is a potentially breaking change to the Python API, but hopefully
this will not impact too many people, and the fix is pretty
easy (switch to using a bool). I've added a NEWS entry to draw
attention to this change.
Approved-By: Tom Tromey <tom@tromey.com>
Building on the previous two commits, I was auditing our uses of
PyObject_IsTrue looking for places where we were missing an error
check.
The gdb.Architecture.integer_type() function takes a 'signed' argument
which should be a 'bool', and the docs do say:
If SIGNED is not specified, it defaults to 'True'. If SIGNED is
'False', the returned type will be unsigned.
Currently we use PyObject_IsTrue, but we are missing an error check.
To fix this I've tightened the code to enforce the bool requirement at
the point that the arguments are parsed. With that done I can remove
the call to PyObject_IsTrue and instead compare to Py_True directly,
the object in question will always be a PyBool_Type.
However, we were testing that passing a non-bool argument for 'signed'
is treated as Py_False, this was added with this commit:
commit 90fe61ced1
Date: Mon Nov 29 13:53:06 2021 +0000
gdb/python: don't use the 'p' format for parsing args
which is when the PyObject_IsTrue call was added. Given that the docs
do seem pretty clear that only True or False are suitable argument
values, my proposal is that we just remove these tests and instead
test that any non-bool argument value for 'signed' gives a TypeError.
This is a breaking change to the Python API, however, my hope is that
this is such a edge case that it will not cause too many problem.
I've added a NEWS entry to highlight this change though.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
After the previous commit I audited all our uses of PyObject_IsTrue
looking for places where we were missing an error check. I did find
some that are missing error checks in places where we really should
have error checks, and I'll fix those in later commits.
This commit however, focuses on those locations where PyObject_IsTrue
is called, there is no error check, and the error check isn't really
necessary because we already know that the object we are dealing with
is of type PyBool_Type.
Inline with the previous commit, in these cases I have removed the
PyObject_IsTrue call, and replaced it with a comparison against
Py_True. In one location where it is not obvious that the object we
have is PyBool_Type I've added an assert, but in the other cases the
comparison to Py_True immediately follows a PyBool_Check call, so an
assert would be redundant.
I've added a test for the gdb.Value.format_string styling argument
being passed a non-bool value as this wasn't previously being tested,
though this new test will pass before and after this commit.
There should be no functional change after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
In this review:
https://inbox.sourceware.org/gdb-patches/87wmirfzih.fsf@tromey.com
Tom pointed out that using PyObject_IsTrue as I was doing, though
technically fine, at least appears to be missing an error check, and
that it would be better to compare to Py_True directly. I made that
change in the patch Tom was commenting on, but I'd actually copied
that code from elsewhere in python/python.c, so this commit updates
the original code inline with Tom's review feedback.
There should be no functional change after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
When running test-case gdb.reverse/time-reverse.exp on arm-linux, I run into:
...
(gdb) continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 403^M
Process record does not support instruction 0xdf00 at address 0xf7ebf774.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0xf7ebf774 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M
(gdb) FAIL: $exp: mode=c: continue to breakpoint: marker2
...
Syscall number 403 stands for clock_gettime64 on arm-linux.
Fix this by handling 403 in arm_canonicalize_syscall, and handling
gdb_sys_clock_gettime64 elsewhere.
Since i386_canonicalize_syscall is the identity function, enum value
gdb_sys_clock_gettime64 gets a value to match i386, which also happens to be
403.
Tested on arm-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com> (record-full)
The dictionary contains a few entries with capital letters:
...
$ grep -E '[A-Z]' .git/wikipedia-common-misspellings.txt | wc -l
143
...
but they don't look too interesting in the gdb context (for instance,
Habsbourg->Habsburg), so filter them out.
That leaves us with entries looking only like "foobat->foobar", so add
handling of capitalized words, such that we also rewrite "Foobat" to "Foobar".
Tested on aarch64-linux. Verified with shellcheck.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Add "doens't->doesn't" to gdb/contrib/common-misspellings.txt, and run
gdb/contrib/spellcheck.sh to fix this in a few files.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Add handling of double quotes in gdb/contrib/spellcheck.sh, and fix the
following typos:
...
inheritence -> inheritance
psuedo -> pseudo
succeded -> succeeded
...
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Currently, text adjacent to parentheses is not spell-checked:
...
$ cat tmp.txt
(upto)
$ ./gdb/contrib/spellcheck.sh tmp.txt
$
...
Add handling of parentheses, such that we get:
...
$ ./gdb/contrib/spellcheck.sh tmp.txt
upto -> up to
$
...
Rerun spellcheck.sh, resulting in a few "thru->through" replacements.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
