| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Printing optc with %c makes sense only when optc is actually a
character. Add logic to also deal with unrecognized long options,
rejected by md_parse_option() rather than get_opt_long_only(). Also
quote the reproduced strings, such that possible included whitespace
can be recognized.
|
|
|
|
Some tests started passing with commit 3a83f0342e54. However,
supporting a changed ld output format is not so simple, and the change
to the loongarch_elf_hash_table macro needs further changes to the
rest of the code. It is true that some uses of
loongarch_elf_hash_table do not need to check the type of the hash
table, but others like loongarch_elf_relax_section do need to check.
bfd_relax_section is called in lang_size_sections using the input bfd,
not the output bfd. If the input bfd may be of different type to the
output, then the hash table type must be checked before accessing
elements of the hash table. This patch corrects
loongarch_elf_relax_section. I haven't checked all the uses of the
hash table throughout the loongarch backend.
bfd/
* elfnn-loongarch.c (loongarch_elf_relax_section): Don't relax
unless the hash table is loongarch_elf_link_hash_table.
Move variable declarations. Formatting.
ld/
* testsuite/ld-elf/pr21884.d: Don't xfail loongarach.
* testsuite/ld-unique/pr21529.d: Likewise.
|
|
|
|
Using 'output' to print arrays larger than max-value-size, with only
repeating elements, can cause gdb to crash:
```
$ cat a.c:
char a[1000000];
int main()
{
return a[0];
}
$ gdb -q a
(gdb) print a
$1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
(gdb) output a
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
Using 'print' works, because value::record_latest sets the unavailable
bytes of the value when it's added to the value history.
But 'outout' doesn't do that, so the printing tries to access more bytes
than are available.
The original problem in PR32015 was about using 'print' of a dynamic
array in a D program.
Here the crash happens because for 'print' the value was a struct with
length/ptr fields, which is converted in d-valprint.c into an array.
So value::record_latest didn't have a chance to mark the unavailable
bytes in this case.
To make sure the unavailable bytes always match the contents, this fixes
it by marking the unavailable bytes immediately after the contents are
allocated.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Replace the scattered and repeated uses of verbose expressions with
variables. E.g.,
ginsn_get_src_reg (src1) -> src1_reg
ginsn_get_src_type (src1) -> src1_type
etc.
This hopefully makes the logic bit more maintainable. While at it,
include minor adjustments to make few checks in gen_scfi_ops () more
precise:
- When getting imm value from src operand, ensure the src type is
GINSN_SRC_IMM,
- When getting reg from src operand, ensure the src type is checked
too (GINSN_SRC_REG or GINSN_SRC_INDIRECT as appropriate).
On the other hand, the changes in verify_heuristic_traceable_reg_fp ()
and verify_heuristic_traceable_stack_manipulation () are purely
mechanical.
gas/
* scfi.c (verify_heuristic_traceable_reg_fp): Add new local
vars and reuse them.
(verify_heuristic_traceable_stack_manipulation): Likewise.
(gen_scfi_ops): Likewise. Additionally, make some conditionals
more precise.
|
|
The `zext.h` is zero-extend halfword instruction that belongs to Zbb.
Currently `zext.h` falls back to 2 shifts if Zbb is not enabled. However, the
encoding and operation is a special case of `pack/packw rd, rs1, rs2`, which
belongs to Zbkb. The instructions pack the low halves of rs1 and rs2 into rd.
When rs2 is zero (x0), they behave like zero-extend instruction, and the
encoding are exactly the same as zext.h.
Thus we can map `zext.h` to `pack` or `packw` (rv64) if Zbkb is enabled,
instead of 2 shifts. This reduces one instruction.
This patch does this by making `zext.h` also available for Zbkb.
opcodes/
* riscv-opc.c (riscv_opcodes): Update `zext.h` entries to use
`ZBB_OR_ZBKB` instruction class.
gas/
* testsuite/gas/riscv/zext-to-pack.s: Add test for mapping zext to
pack/packw encoding.
* testsuite/gas/riscv/zext-to-pack-encoding.d: Likewise.
* testsuite/gas/riscv/zext-to-packw-encoding.d: Likewise.
|
|
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html
Contributors:
Mary Bennett <mary.bennett682@gmail.com>
Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Pietra Ferreira <pietra.ferreira@embecosm.com>
Charlie Keaney
Jessica Mills
Craig Blackmore <craig.blackmore@embecosm.com>
Simon Cook <simon.cook@embecosm.com>
Jeremy Bennett <jeremy.bennett@embecosm.com>
Helene Chelin <helene.chelin@embecosm.com>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvbitmanip`
instruction class.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): Add custom operands `Xc6` and `Xc7`.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Note XCVbitmanip as an additional ISA extension
for CORE-V.
* testsuite/gas/riscv/march-help.l: Add xcvbitmanip.
* testsuite/gas/riscv/x-cv-bitmanip-fail.d: New Test.
* testsuite/gas/riscv/x-cv-bitmanip-fail.l: New Test.
* testsuite/gas/riscv/x-cv-bitmanip-fail.s: New Test.
* testsuite/gas/riscv/x-cv-bitmanip.d: New Test.
* testsuite/gas/riscv/x-cv-bitmanip.s: New Test.
include/opcode/ChangeLog:
* riscv-opc.h: Add corresponding MATCH and MASK macros for
XCVbitmanip.
* riscv.h: Add corresponding EXTRACT and ENCODE macros for
XCVbitmanip.
(enum riscv_insn_class): Add the XCVbitmanip instruction class.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Add custom operands `Xc6` and `Xc7`.
* riscv-opc.c: Add XCvBitmanip instructions.
|
|
This implements the Zcmop (Compressed Zimop) extension, as of version 1.0.
View detailed information in:
<https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc>
The Zcmop extension requires the Zca extension.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Handle Zcmop.
(riscv_multi_subset_supports_ext): Ditto.
gas/ChangeLog:
* NEWS: Updated.
* testsuite/gas/riscv/march-help.l: Ditto.
* testsuite/gas/riscv/zcmop.d: New test.
* testsuite/gas/riscv/zcmop.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h (DECLARE_INSN): New declarations for Zcmop.
(MATCH_C_MOP_1, MATCH_C_MOP_3, MATCH_C_MOP_5, MATCH_C_MOP_7,
MATCH_C_MOP_9, MATCH_C_MOP_11, MATCH_C_MOP_13, MATCH_C_MOP_15): Define.
(MASK_C_MOP_1, MASK_C_MOP_3, MASK_C_MOP_5, MASK_C_MOP_7,
MASK_C_MOP_9, MASK_C_MOP_11, MASK_C_MOP_13, MASK_C_MOP_15): Ditto.
* opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZCMOP.
opcodes/ChangeLog:
* riscv-opc.c: Add Zcmop instructions.
|
|
This implements the Zimop (May-Be-Operations) extension, as of version 1.0.
View detailed information in:
<https://github.com/riscv/riscv-isa-manual/blob/main/src/zimop.adoc>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Handle Zimop
(riscv_multi_subset_supports_ext): Ditto.
gas/ChangeLog:
* NEWS: Updated.
* testsuite/gas/riscv/march-help.l: Ditto.
* testsuite/gas/riscv/zimop.d: New test.
* testsuite/gas/riscv/zimop.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h (DECLARE_INSN): New declarations for Zimop.
(MATCH_MOP_R_0, MATCH_MOP_R_1, MATCH_MOP_R_2, MATCH_MOP_R_3,
MATCH_MOP_R_4, MATCH_MOP_R_5, MATCH_MOP_R_6, MATCH_MOP_R_7,
MATCH_MOP_R_8, MATCH_MOP_R_9, MATCH_MOP_R_10, MATCH_MOP_R_11,
MATCH_MOP_R_12, MATCH_MOP_R_13, MATCH_MOP_R_14, MATCH_MOP_R_15,
MATCH_MOP_R_16, MATCH_MOP_R_17, MATCH_MOP_R_18, MATCH_MOP_R_19,
MATCH_MOP_R_20, MATCH_MOP_R_21, MATCH_MOP_R_22, MATCH_MOP_R_23,
MATCH_MOP_R_24, MATCH_MOP_R_25, MATCH_MOP_R_26, MATCH_MOP_R_27,
MATCH_MOP_R_28, MATCH_MOP_R_29, MATCH_MOP_R_30, MATCH_MOP_R_31,
MATCH_MOP_RR_0, MATCH_MOP_RR_1, MATCH_MOP_RR_2, MATCH_MOP_RR_3,
MATCH_MOP_RR_4, MATCH_MOP_RR_5, MATCH_MOP_RR_6, MATCH_MOP_RR_7): Define.
(MASK_MOP_R_0, MASK_MOP_R_1, MASK_MOP_R_2, MASK_MOP_R_3, MASK_MOP_R_4,
MASK_MOP_R_5, MASK_MOP_R_6, MASK_MOP_R_7, MASK_MOP_R_8, MASK_MOP_R_9,
MASK_MOP_R_10, MASK_MOP_R_11, MASK_MOP_R_12, MASK_MOP_R_13,
MASK_MOP_R_14, MASK_MOP_R_15, MASK_MOP_R_16, MASK_MOP_R_17,
MASK_MOP_R_18, MASK_MOP_R_19, MASK_MOP_R_20, MASK_MOP_R_21,
MASK_MOP_R_22, MASK_MOP_R_23, MASK_MOP_R_24, MASK_MOP_R_25,
MASK_MOP_R_26, MASK_MOP_R_27, MASK_MOP_R_28, MASK_MOP_R_29,
MASK_MOP_R_30, MASK_MOP_R_31, MASK_MOP_RR_0, MASK_MOP_RR_1,
MASK_MOP_RR_2, MASK_MOP_RR_3, MASK_MOP_RR_4, MASK_MOP_RR_5,
MASK_MOP_RR_6, MASK_MOP_RR_7): Ditto.
* opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZIMOP.
opcodes/ChangeLog:
* riscv-opc.c: Add Zimop instructions.
|
|
|
|
For clarity and symmetry with `gdbarch-gen.h`. I wouldn't mind
if all generated files had the `-gen` suffix.
Change-Id: Icb70194fb0e3e2fa9d1c6f0d9331be09b805b428
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Maintaining line numbers correctly both inside the region and past it
requires special care. The SB produced there is somewhat different from
that produced for e.g. macro expansions, and hence also needs treating
differently: In particular we aren't doing anything resembling macro
expansion here.
The new testcase may be a little misplaced in macros/, but that's where
all the other #APP / #NO_APP ones are.
|
|
For one '#' may not be in line_comment_chars[] in the first place. Look
for just it when it is (these "directives" are akin to C preprocessor
directives after all), but accept any other line comment character
otherwise (in read.c further requiring a match on the counterpart
"directive").
Then, when in the middle of a file, the constructs should be all on
their own on a line. There needs to be a newline ahead of them and
after them.
Finally '\n' may not be the only end-of-line character. Accept any (but
not end-of-statement ones) in read.c, while making sure in input-file.c
there is one in the first place - merely any kind of whitespace isn't
good enough.
|
|
It's not valid to recognize it after mere line separators (often
semicolon) or after labels, let alone after tc_unrecognized_line()
perhaps having parsed off parts of a line. It shouldn't even be
preceded by whitespace, aiui.
However, keep ignoring line comments as before, for backwards
compatibility.
|
|
Consider the following test-case:
...
$ cat -n test.c
1 int var;
2
3 int
4 foo (void)
5 {
6 var = 1;
7 #include "test.h"
8 }
9
10 int
11 main ()
12 {
13 return foo ();
14 }
$ cat -n test.h
1 return 1;
$ gcc test.c -g
...
When stepping through the test-case, gdb doesn't make it explicit that line 1
is not in test.c:
...
Temporary breakpoint 1, main () at test.c:13
13 return foo ();
(gdb) step
foo () at test.c:6
6 var = 1;
(gdb) n
1 return 1;
(gdb)
8 }
(gdb)
...
which makes it easy to misinterpret the output.
This is with the default "print frame-info" == auto, with documented
behaviour [1]:
...
stepi will switch between source-line and source-and-location depending on the
program counter.
...
What is actually implemented is that source-line is used unless stepping into
or out of a function.
The problem can be worked around by using
"set print frame-info source-and-location", but that's a bit verbose.
Instead, change the behaviour of "print frame-info" == auto to also use
source-and-location when stepping into another file, which gets us:
...
(gdb) n
foo () at test.h:1
1 return 1;
...
Tested on x86_64-linux.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
PR gdb/32011
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32011
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Print-Settings.html#index-set-print-frame_002dinfo
|
|
In binary output format, loongarch_elf_hash_table return NULL and result
in segment fault.
When ld output binary file, it seems that elf related functions should
not be called. But loongarch_elf_relax_section be called and
loongarch_elf_hash_table cause segment fault.
Just redefined loongarch_elf_hash_table and always return
link_info->hash.
The tests of binutils, glibc and gcc is ok.
0 loongarch_elf_relax_section ()
1 0x000055555557ab28 in lang_size_sections_1 ()
2 0x000055555557a16c in lang_size_sections_1 ()
3 0x000055555557b0a8 in one_lang_size_sections_pass ()
4 0x000055555557b478 in lang_size_sections ()
5 0x000055555557e65c in lang_relax_sections ()
6 0x000055555559f9c8 in ldelf_map_segments ()
7 0x000055555559783c in gldelf64loongarch_after_allocation ()
8 0x000055555558dac0 in ldemul_after_allocation ()
9 0x000055555557f6c0 in lang_process ()
10 0x0000555555585314 in main ()
|
|
|
|
|
|
|
|
Call unwrap_hash_lookup to restore the wrapper symbol check for standard
function since reference to standard function may not show up in LTO
symbol table:
[hjl@gnu-tgl-3 pr31956-3]$ nm foo.o
00000000 T main
U __real_malloc
00000000 T __wrap_malloc
[hjl@gnu-tgl-3 pr31956-3]$ lto-dump -list foo.o
Type Visibility Size Name
function default 0 malloc
function default 0 __real_malloc
function default 3 main
function default 5 __wrap_malloc
[hjl@gnu-tgl-3 pr31956-3]$ make
gcc -O2 -flto -Wall -c -o foo.o foo.c
gcc -Wl,--wrap=malloc -O2 -flto -Wall -o x foo.o
/usr/local/bin/ld: /tmp/ccsPW0a9.ltrans0.ltrans.o: in function `main':
<artificial>:(.text.startup+0xa): undefined reference to `__wrap_malloc'
collect2: error: ld returned 1 exit status
make: *** [Makefile:22: x] Error 1
[hjl@gnu-tgl-3 pr31956-3]$
Also add a test to verify that the unused wrapper is removed.
PR ld/31956
* plugin.c (get_symbols): Restore the wrapper symbol check for
standard function.
* testsuite/ld-plugin/lto.exp: Run the malloc test and the
unused test.
* testsuite/ld-plugin/pr31956c.c: New file.
* testsuite/ld-plugin/pr31956d.c: New file.
* testsuite/ld-plugin/pr31956d.d: New file.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
|
|
Now that all known uses of VLAs within GDB are removed, remove the
`-Wno-vla-cxx-extension` (which was used to silence clang warnings) and
add `-Wvla`, such that any use of a VLA will trigger a warning.
Change-Id: I69a8d7f93f973743165b0ba46f9c2ea8adb89025
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
Remove uses of VLAs, replace with gdb::byte_vector. There might be more
in files that I can't compile, but it's difficult to tell without
actually compiling on all platforms.
Many thanks to the Linaro pre-commit CI for helping find some problems
with an earlier iteration of this patch.
Change-Id: I3e5e34fcac51f3e6b732bb801c77944e010b162e
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
Thiago Jung Bauermann noticed that gdb.base/list-dot-nodebug was not
actually compiling the test with some debuginfo in the relevant part,
and while fixing I noticed that the base assumption of the "some" case
was wrong, GDB would select some symtab as a default location and the
test would always fail. This fix makes printing the default location
only be tested when there is no debuginfo.
When testing with no debuginfo, if a system had static libc debuginfo,
the test would also fail. To add an extra layer of robustness to the
test, this rewrite also strips any stray debuginfo from the executable.
The test would only fail now if it runs in a system that can't handle
stripped debuginfo and has static debuginfo pre-installed.
Reported-By: Tom de Vries <tdevries@suse.de>
Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
While reviewing [1], it occurred to me that having both the
skipped_frames counter and the skipped_syms vector is redundant. When
stepping into an inline frame, we can just pop the last element.
[1] https://inbox.sourceware.org/gdb-patches/96cfee31-6a50-4a78-a25b-67e5d061c2a3@simark.ca/T/#m7e0e4b5b6cfc91be3d8ab6d5025a97c2e647103a
Change-Id: I8c10e7fcd05e41c2c838431d06c9e793d18a2198
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
|
|
PR 31940
|
|
The final test of gdb.python/py-framefilter-invalidarg.exp expected that
the the backtrace only printed the source file name. However, when using
clang, gdb will always print the full path to the file, which would
cause the test to fail. This commit introduces a regexp that optionally
matches paths, preprended to the file name, which fixes the clang
failure without introducing gcc failures.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The test gdb.fortran/entry-point.exp already has an XFAIL when trying to
set a breakpoint in mod::mod_foo because gcc puts that subprogram in the
wrong scope in the debug information. Clang's debug information looks
the same as gcc's, so the test to setup the xfail has been extended to
also include clang.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Clang doesn't add build-id information by default, unlike gcc. This
means that tests that rely on build-id being available and don't
explicitly add it to the compilation options will fail with clang.
This commit fixes the fails in gdb.python/py-missing-debug.exp,
gdb.server/remote-read-msgs.exp, gdb.base/coredump-filter-build-id.exp
and gdb.server/solib-list.exp
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The override is necessary only when a target needs other than an array
of const char.
For cris drop redundant sibling declarations at the same time.
|
|
Internal naming of functions / data as well as commentary mixes lines
and statements. It is presumably this confusion which has led to the
wrong use of ignore_rest_of_line() when dealing with line comments in
read_a_source_file(). We shall not (silently) produce different output
depending on whether -f is passed (for suitable input).
Introduce two new helper macros, intended to be used in favor of open-
coded accesses to is_end_of_line[]. To emphasize the difference, convert
ignore_rest_of_line() right away, including adjustments to its comments.
Since most targets have # in line_comment_chars[], add a target-
independent test for that, plus an x86-only one also checking for non-#
to work as intended.
|
|
|
|
Keep the two symmetrical looking. Makes sense to perform the sanity
checks similarly too.
gas/
* ginsn.c (ginsn_src_print): Buffer up result of snprintf and
add sanity checks on the value.
(ginsn_dst_print): Use switch case instead.
|
|
For ginsns with less than 2 source operands or no destination operands,
the current textual dump contains a superfluous comma, like the relevant
testcases show.
Adjust the code a bit to not emit the lone trailing comma. Also, adjust
the aarch64 and x86_64 testcases.
gas/
* ginsn.c (ginsn_src_print): Do not use a trailing comma when
printing the src of ginsn.
(ginsn_print): Check the strlen and prefix a comma before the
src string.
gas/testsuite/
* gas/scfi/aarch64/ginsn-cofi-1.l: Adjust the expected textual
dump of the ginsn.
* gas/scfi/x86_64/ginsn-cofi-1.l: Likewise.
|
|
Some flavors of indirect call and jmp instructions were not being
handled earlier, leading to a GAS error (#1):
(#1) "Error: SCFI: unhandled op 0xff may cause incorrect CFI"
Not handling jmp/call (direct or indirect) ops is an error (as shown
above) because SCFI needs an accurate CFG to synthesize CFI correctly.
Recall that the presence of indirect jmp/call, however, does make the
CFG ineligible for SCFI. In other words, generating the ginsns for them
now, will eventually cause SCFI to bail out later with an error (#2)
anyway:
(#2) "Error: untraceable control flow for func 'XXX'"
The first error (#1) gives the impression of missing functionality in
GAS. So, it seems cleaner to synthesize a GINSN_TYPE_JUMP /
GINSN_TYPE_CALL now in the backend, and let SCFI machinery complain with
the error as expected.
The handling for these indirect jmp/call instructions is similar, so
reuse the code by carving out a function for the same.
Adjust the testcase to include the now handled jmp/call instructions as
well.
gas/
* config/tc-i386-ginsn.c (x86_ginsn_indirect_branch): New
function.
(x86_ginsn_new): Refactor out functionality to above.
gas/testsuite/
* gas/scfi/x86_64/ginsn-cofi-1.l: Adjust the output.
* gas/scfi/x86_64/ginsn-cofi-1.s: Add further varieties of
jmp/call opcodes.
|
|
This patch register the command "maint set show-debug-regs on/off"
and make it settable by the user. If show-debug-regs is enabled,
the debug register values are shown when GDB inserts or removes a
hardware breakpoint or watchpoint. This is helpful for the use and
development of hardware watchpoints.
With this patch, the effect of this maintenance command as follows:
lihui@bogon:~$ cat test.c
int a = 0;
int main()
{
a = 1;
return 0;
}
lihui@bogon:~$ gcc -g test.c -o test
lihui@bogon:~$ gdb test
...
(gdb) watch a
Hardware watchpoint 1: a
(gdb) maint set show-debug-regs on
(gdb) r
Starting program: /home/lihui/test
...
...
prepare_to_resume thread 41525
...
insert_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint):
BREAKPOINTs:
BP0: addr=0x0, ctrl=0x00000000, ref.count=0
BP1: addr=0x0, ctrl=0x00000000, ref.count=0
BP2: addr=0x0, ctrl=0x00000000, ref.count=0
BP3: addr=0x0, ctrl=0x00000000, ref.count=0
BP4: addr=0x0, ctrl=0x00000000, ref.count=0
BP5: addr=0x0, ctrl=0x00000000, ref.count=0
BP6: addr=0x0, ctrl=0x00000000, ref.count=0
BP7: addr=0x0, ctrl=0x00000000, ref.count=0
WATCHPOINTs:
WP0: addr=0x0, ctrl=0x00000000, ref.count=0
WP1: addr=0x0, ctrl=0x00000000, ref.count=0
WP2: addr=0x0, ctrl=0x00000000, ref.count=0
WP3: addr=0x0, ctrl=0x00000000, ref.count=0
WP4: addr=0x0, ctrl=0x00000000, ref.count=0
WP5: addr=0x0, ctrl=0x00000000, ref.count=0
WP6: addr=0x0, ctrl=0x00000000, ref.count=0
WP7: addr=0x12000803c, ctrl=0x00000610, ref.count=1
...
remove_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint):
BREAKPOINTs:
BP0: addr=0x0, ctrl=0x00000000, ref.count=0
BP1: addr=0x0, ctrl=0x00000000, ref.count=0
BP2: addr=0x0, ctrl=0x00000000, ref.count=0
BP3: addr=0x0, ctrl=0x00000000, ref.count=0
BP4: addr=0x0, ctrl=0x00000000, ref.count=0
BP5: addr=0x0, ctrl=0x00000000, ref.count=0
BP6: addr=0x0, ctrl=0x00000000, ref.count=0
BP7: addr=0x0, ctrl=0x00000000, ref.count=0
WATCHPOINTs:
WP0: addr=0x0, ctrl=0x00000000, ref.count=0
WP1: addr=0x0, ctrl=0x00000000, ref.count=0
WP2: addr=0x0, ctrl=0x00000000, ref.count=0
WP3: addr=0x0, ctrl=0x00000000, ref.count=0
WP4: addr=0x0, ctrl=0x00000000, ref.count=0
WP5: addr=0x0, ctrl=0x00000000, ref.count=0
WP6: addr=0x0, ctrl=0x00000000, ref.count=0
WP7: addr=0x0, ctrl=0x00000000, ref.count=0
Hardware watchpoint 1: a
Old value = 0
New value = 1
main () at test.c:5
5 return 0;
(gdb)
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
get_type_abbrev_from_form is lax in not limiting data for a uleb to
the current CU, because DW_FORM_ref_addr allows access to other CU's
data. This can lead to an assertion fail when skipping or reading
attributes in get_type_signedness.
* dwarf.c (get_type_abbrev_from_form): Limit uleb data to map end
for ref_addr, cu_end otherwise.
|
|
This commit moves aarch64_linux_memtag_matches_p,
aarch64_linux_set_memtags, aarch64_linux_get_memtag, and
aarch64_linux_memtag_to_string hooks (plus the aarch64_mte_get_atag
function used by them), along with the setting of the memtag granule
size, from aarch64-linux-tdep.c to aarch64-tdep.c, making MTE available
on baremetal targets. Since the aarch64-linux-tdep.c layer inherits
these hooks from aarch64-tdep.c, there is no effective change for
aarch64-linux targets.
Helpers used both by aarch64-tdep.c and by aarch64-linux-tdep.c were
moved from arch/aarch64-mte-linux.{c,h} to new arch/aarch64-mte.{c,h}
files.
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
Tested-By: Luis Machado <luis.machado@arm.com>
Approved-By: Luis Machado <luis.machado@arm.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
On fedora rawhide, with python 3.13, I run into:
...
(gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M
Python Exception <class 'TypeError'>: \
this function got an unexpected keyword argument 'invalid'^M
Error occurred in Python: \
this function got an unexpected keyword argument 'invalid'^M
(gdb) FAIL: $exp: format_string: lang_c: test_all_common: test_invalid_args: \
a_point_t with option invalid=True
...
A passing version with an older python version looks like:
...
(gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M
Python Exception <class 'TypeError'>: \
'invalid' is an invalid keyword argument for this function^M
Error occurred in Python: \
'invalid' is an invalid keyword argument for this function^M
(gdb) PASS: $exp: format_string: lang_c: test_all_common: test_invalid_args: \
a_point_t with option invalid=True
...
Fix this by accepting the updated error message.
Tested on aarch64-linux.
PR testsuite/31912
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31912
|
|
To avoid differences in C library paths on different systems
use gcc instead of ld to perform the test.
Problems caused by adding options to different distributions
will not be fixed.
|
|
Empty structs in C++ lead to empty LF_FIELDLIST types in the .debug$T
section, but we were mistakenly rejecting these as invalid. Allow
CodeView types of two bytes, and add a test for this.
|
|
|
|
This failed to properly byteswap its return value.
The ctf_archive format predates the idea of "just write natively and
flip on open", and byteswaps all over the place. It's too easy to
forget one. The next revision of the archive format (not versioned,
so we just tweak the magic number instead) should be native-endianned
like the dicts inside it are.
libctf/
* ctf-archive.c (ctf_archive_count): Byteswap return value.
|
|
If you asprintf something and then use it only as input to another asprintf,
it helps to free it afterwards.
libctf/
* ctf-dump.c (ctf_dump_header): Free the flagstr after use.
(ctf_dump): Make a NULL return slightly clearer.
|
|
A bug in ctf_dtd_delete led to refs in the string table to the
names of non-root-visible types not being removed when the DTD
was. This seems harmless, but actually it would lead to a write
down a pointer into freed memory if such a type was ctf_rollback()ed
over and then the dict was serialized (updating all the refs as the
strtab was serialized in turn).
Bug introduced in commit fe4c2d55634c700ba527ac4183e05c66e9f93c62
("libctf: create: non-root-visible types should not appear in name tables")
which is included in binutils 2.35.
libctf/
* ctf-create.c (ctf_dtd_delete): Remove refs for all types
with names, not just root-visible ones.
|
|
The dict and archive opening code in libctf is somewhat unusual, because
unlike everything else, it cannot report errors by setting an error on the
dict, because in case of error there isn't one. They get passed an error
integer pointer that is set on error instead.
Inside ctf_bufopen this is implemented by calling ctf_set_open_errno and
passing it a positive error value. In turn this means that most things it
calls (including init_static_types) return zero on success and a *positive*
ECTF_* or errno value on error.
This trickles down to ctf_dynhash_insert_type, which is used by
init_static_types to add newly-detected types to the name tables. This was
returning the error value it received from a variety of functions without
alteration. ctf_dynhash_insert conformed to this contract by returning a
positive value on error (usually OOM), which is unfortunate for multiple
reasons:
- ctf_dynset_insert returns a *negative* value
- ctf_dynhash_insert and ctf_dynset_insert don't take an fp, so the value
they return is turned into the errno, so it had better be right, callers
don't just check for != 0 here
- more or less every single caller of ctf_dyn*_insert in libctf other than
ctf_dynhash_insert_type (and there are a *lot*, mostly in the
deduplicator) assumes that ctf_dynhash_insert returns a negative value
on error, even though it doesn't. In practice the only possible error is
OOM, but if OOM does happen we end up with a nonsense error value.
The simplest fix for this seems to be to make ctf_dynhash_insert and
ctf_dynset_insert conform to the usual interface contract: negative
values are errors. This in turn means that ctf_dynhash_insert_type
needs to change: let's make it consistent too, returning a negative
value on error, putting the error on the fp in non-negated form.
init_static_types_internal adapts to this by negating the error return from
ctf_dynhash_insert_type, so the value handed back to ctf_bufopen is still
positive: the new call site in ctf_track_enumerator does not need to change.
(The existing tests for this reliably detect when I get it wrong.
I know, because they did.)
libctf/
* ctf-hash.c (ctf_dynhash_insert): Negate return value.
(ctf_dynhash_insert_type): Set de-negated error on the dict:
return negated error.
* ctf-open.c (init_static_types_internal): Adapt to this change.
|
|
The recent change to detect duplicate enum values and return ECTF_DUPLICATE
when found turns out to perturb a great many callers. In particular, the
pahole-created kernel BTF has the same problem we historically did, and
gleefully emits duplicated enum constants in profusion. Handling the
resulting duplicate errors from BTF -> CTF converters reasonably is
unreasonably difficult (it amounts to forcing them to skip some types or
reimplement the deduplicator).
So let's step back a bit. What we care about mostly is that the
deduplicator treat enums with conflicting enumeration constants as
conflicting types: programs that want to look up enumeration constant ->
value mappings using the new APIs to do so might well want the same checks
to apply to any ctf_add_* operations they carry out (and since they're
*using* the new APIs, added at the same time as this restriction was
imposed, there is likely to be no negative consequence of this).
So we want some way to allow processes that know about duplicate detection
to opt into it, while allowing everyone else to stay clear of it: but we
want ctf_link to get this behaviour even if its caller has opted out.
So add a new concept to the API: dict-wide CTF flags, set via
ctf_dict_set_flag, obtained via ctf_dict_get_flag. They are not bitflags
but simple arbitrary integers and an on/off value, stored in an unspecified
manner (the one current flag, we translate into an LCTF_* flag value in the
internal ctf_dict ctf_flags word). If you pass in an invalid flag or value
you get a new ECTF_BADFLAG error, so the caller can easily tell whether
flags added in future are valid with a particular libctf or not.
We check this flag in ctf_add_enumerator, and set it around the link
(including on child per-CU dicts). The newish enumerator-iteration test is
souped up to check the semantics of the flag as well.
The fact that the flag can be set and unset at any time has curious
consequences. You can unset the flag, insert a pile of duplicates, then set
it and expect the new duplicates to be detected, not only by
ctf_add_enumerator but also by ctf_lookup_enumerator. This means we now
have to maintain the ctf_names and conflicting_enums enum-duplication
tracking as new enums are added, not purely as the dict is opened.
Move that code out of init_static_types_internal and into a new
ctf_track_enumerator function that addition can also call.
(None of this affects the file format or serialization machinery, which has
to be able to handle duplicate enumeration constants no matter what.)
include/
* ctf-api.h (CTF_ERRORS) [ECTF_BADFLAG]: New.
(ECTF_NERR): Update.
(CTF_STRICT_NO_DUP_ENUMERATORS): New flag.
(ctf_dict_set_flag): New function.
(ctf_dict_get_flag): Likewise.
libctf/
* ctf-impl.h (LCTF_STRICT_NO_DUP_ENUMERATORS): New flag.
(ctf_track_enumerator): Declare.
* ctf-dedup.c (ctf_dedup_emit_type): Set it.
* ctf-link.c (ctf_create_per_cu): Likewise.
(ctf_link_deduplicating_per_cu): Likewise.
(ctf_link): Likewise.
(ctf_link_write): Likewise.
* ctf-subr.c (ctf_dict_set_flag): New function.
(ctf_dict_get_flag): New function.
* ctf-open.c (init_static_types_internal): Move enum tracking to...
* ctf-create.c (ctf_track_enumerator): ... this new function.
(ctf_add_enumerator): Call it.
* libctf.ver: Add the new functions.
* testsuite/libctf-lookup/enumerator-iteration.c: Test them.
|
|
It applies to enums now, so it should mention them.
include/
* ctf-api.h (_CTF_ERRORS) ECTF_DUPLICATE]: Mention enums.
|
