ROCgdb master → amd-staging conflict-free: afa6db16e650..4ed310516eb7 - #293
Open
github-actions[bot] wants to merge 17 commits into
Open
Conversation
When building on macOS, I get:
CC z80-dis.lo
/Users/smarchi/src/binutils-gdb/opcodes/z80-dis.c:804:41: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
804 | info->fprintf_func = (fprintf_ftype) &sprintf;
| ^
Replace this use of sprintf with the safer snprintf. Add a small
structure and wrappers around snprintf in order to glue everything
together.
When asked to review my patch, Claude Code mentioned that the existing
code had a latent bug: while info->fprintf_func and info->stream get set
temporarily, info->fprintf_styled_func doesn't. If fprintf_styled_func
happened to be called, it would receive a `stream` it doesn't expect.
It's probably not a problem today, if the disassembler doesn't emit
styling, but it seems like a good moment to fix it. Use
the disassemble_set_printf function to set both fprintf functions and
the stream argument at the same time.
Change-Id: I85dee82f3a0c53f38e52ca1158bc605854ab4896
gnat-llvm emits a slightly different encoding for Ada unchecked unions. This encoding lets GDB resolve the discriminant for some branches that appear as "?" when compiled with GCC's GNAT. This patch updates gdb.ada/unchecked_union.exp to allow this. Approved-By: Andrew Burgess <aburgess@redhat.com>
When building on macOS, I get:
CXX common-utils.o
/Users/smarchi/src/binutils-gdb/gdbsupport/common-utils.cc:106:3: error: 'vsprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use vsnprintf(3) instead. [-Werror,-Wdeprecated-declarations]
106 | vsprintf (&str[0], fmt, vp);
| ^
/Users/smarchi/src/binutils-gdb/gdbsupport/common-utils.cc:128:3: error: 'vsprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use vsnprintf(3) instead. [-Werror,-Wdeprecated-declarations]
128 | vsprintf (&str[0], fmt, args);
| ^
/Users/smarchi/src/binutils-gdb/gdbsupport/common-utils.cc:166:3: error: 'vsprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use vsnprintf(3) instead. [-Werror,-Wdeprecated-declarations]
166 | vsprintf (&str[curr_size], fmt, args);
| ^
We know that those calls should be safe because we computed the size that
fmt+args take just before, and allocated that many bytes. But I also
don't see a real downside in switching those calls to use vsnprintf and
double check that everything went right.
Change the type of the existing "size" variable in "string_vprintf" to
"int", since that's what vsnprintf returns.
Change-Id: I589d9a170fdd15cc31b44b76689c6d8c324e340a
Approved-By: Andrew Burgess <aburgess@redhat.com>
When building on macOS, I get some errors about the uses of sprintf:
CXX xml-utils.o
/Users/smarchi/src/binutils-gdb/gdbsupport/xml-utils.cc:91:8: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
91 | sprintf (str, "%d", va_arg (ap, int));
| ^
We know they are safe, because the 32 byte destination buffer is large
enough for all conversions. But I also don't think it's a big deal to
switch to xsnprintf to avoid these errors, and to catch any future
error.
Change-Id: If3531e1916e103dfccd0ec033639b14a2b6df3cf
Approved-By: Andrew Burgess <aburgess@redhat.com>
When building on macOS, whose sed is the BSD one, I get:
GEN ppc/stamp-defines
sed: 1: "/^#define HAVE_.*1$/{ s ...": extra characters at the end of p command
make[1]: *** [ppc/stamp-defines] Error 1
BSD sed apparently does not accept a `}' directly after another command,
it needs a separating semicolon. Add one after the `p'. GNU sed
accepts both forms, and produces the same output either way.
Re-generate sim/Makefile.in.
Change-Id: I0709ad7b0051e08299f2576113b549aba9fc703f
Approved-By: Andrew Burgess <aburgess@redhat.com>
When building on macOS, I get:
/Users/smarchi/src/binutils-gdb/sim/m32r/traps.c:191:18: error: unused variable 'cb' [-Werror,-Wunused-variable]
191 | host_callback *cb = STATE_CALLBACK (sd);
| ^~
All the uses of `cb' in m32r_trap are inside the TRAP_LINUX_SYSCALL
case, which is guarded by `#ifdef __linux__'. Move the declaration
inside that case, so that it only exists where it is used.
Change-Id: I609850daf7fa60d92856988dffe7e314eb1d8a30
Approved-By: Andrew Burgess <aburgess@redhat.com>
When building on macOS, I get:
/Users/smarchi/src/binutils-gdb/sim/m32r/traps.c:141:1: error: unused function 't2h_addr' [-Werror,-Wunused-function]
141 | t2h_addr (host_callback *cb, struct cb_syscall *sc,
| ^~~~~~~~
/Users/smarchi/src/binutils-gdb/sim/m32r/traps.c:158:1: error: unused function 'translate_endian_h2t' [-Werror,-Wunused-function]
158 | translate_endian_h2t (void *addr, size_t size)
| ^~~~~~~~~~~~~~~~~~~~
/Users/smarchi/src/binutils-gdb/sim/m32r/traps.c:171:1: error: unused function 'translate_endian_t2h' [-Werror,-Wunused-function]
171 | translate_endian_t2h (void *addr, size_t size)
| ^~~~~~~~~~~~~~~~~~~~
These three helpers are only called from the TRAP_LINUX_SYSCALL case,
which is guarded by `#ifdef __linux__'. Put them behind the same guard.
Change-Id: I8c8744727eb27abc08231be2a10f8d0de44d7ea6
Approved-By: Andrew Burgess <aburgess@redhat.com>
When building on macOS, I get some:
/Users/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3773:4: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
3773 | sprintf (buf, "TU %s at offset %s", hex_string (sig_type->signature),
| ^
Replace them with xsnprintf, which takes the destination size and asserts
that the output was not truncated.
Change-Id: Ie0324f75e5d4aad9b647007848459bf4af5998a6
Approved-By: Andrew Burgess <aburgess@redhat.com>
When building on macOS, I get:
/Users/smarchi/src/binutils-gdb/gdb/elfread.c:813:3: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
813 | sprintf (name_got_plt, "%s" SYMBOL_GOT_PLT_SUFFIX, name);
| ^
Change this use of sprintf with an std::string, which also allows
getting rid of a use of alloca.
Change-Id: I296e25c863463ef05eca582c8303557570d63cf0
Approved-By: Andrew Burgess <aburgess@redhat.com>
When building on macOS, I get some:
/Users/smarchi/src/binutils-gdb/gdb/tracepoint.c:1196:4: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
1196 | sprintf (end, "M-1,%s,%lX", phex_nz (m_memranges[i].start, 0),
| ^
Replace them with xsnprintf.
Change-Id: Id3ec76c47e5c0091fa3a028e36063b2115378e7e
Approved-By: Andrew Burgess <aburgess@redhat.com>
On Fedora Rawhide aarch64-linux, I ran into:
...
builtin_spawn $build/gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 \
-data-directory $build/gdb/data-directory -iex set interactive-mode on
WARN: Could not find the standard library directory! The Python 'home'
directory was set to 'foo', is this correct?
Error occurred computing Python error message.
$build/gdb/gdb: warning:
Could not load the Python gdb module from
`$build/gdb/data-directory/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.
(gdb) set height 0
(gdb) set width 0
(gdb) dir
Reinitialize source path to empty? (y or n) y
Source directories searched: $cdir:$cwd
(gdb) dir $src/gdb/testsuite/gdb.python
Source directories searched:
$src/gdb/testsuite/gdb.python:$cdir:$cwd
(gdb) python print (1)
1
(gdb) FAIL: $exp: gdb-command<python print (1)>
quit
Exception ignored on threading shutdown:
Traceback (most recent call last):
File "<string>", line 2, in <module>
ModuleNotFoundError: No module named 'importlib'
PASS: gdb.python/py-failed-init.exp: quit
...
The ModuleNotFoundError reported after quit originates from
gdbpy_initialize_gdb_readline. I've filed a PR about this [1].
The test-case tries to break python:
...
save_vars { env(PYTHONHOME) } {
setenv PYTHONHOME foo
clean_restart
}
...
enough to get it to this point:
...
gdb_test "python print (1)" \
"Python not initialized"
...
but apparently, that doesn't work anymore in this python version:
...
$ python --version
Python 3.15.0b4
...
Update the test-case by simply accepting the output.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=34485
Since 2.47, ld rejects a perfectly ordinary link on native Windows: ld.exe: error: linker script file '../common_arm/ldscript.common (ldscript-flash)' appears multiple times when the only thing on the command line is a single -T, and that script INCLUDEs one other file. The two names in the message are the giveaway: the file being opened and an entry already recorded are different files, so the comparison that matched them is wrong. Two changes stack up to produce it. d048eee ("ld: Use stat to check if linker script appears multiple times") changed the PR 24576 check from a name comparison to stat plus SAME_INODE. Then 47071f8 ("same-inode.h: don't depend on _GL_WINDOWS_STAT_INODES") dropped the guard in include/same-inode.h that had been expanding SAME_INODE to a literal 0 on native Windows. binutils never defines _GL_WINDOWS_STAT_INODES, so on Windows the check went from dead code to live in one release. The Windows CRT sets st_ino to 0 for every file. The guard that survived only rejects st_ino == 0 && st_dev == 0, and st_dev is the drive number, so on D: it is 3 and the guard passes. Every file on the drive then compares equal to every other file, and the first INCLUDE inside a -T script looks like a repeat of the script itself. The commit message of 47071f8 anticipates this: "this doesn't really make SAME_INODE usable on windows hosts as a number of the likely filesystems (FAT, HPFS, or NTFS) don't support st_ino." Fall back to comparing file names when stat gives no usable inode, so the duplicate detection keeps working on hosts where inodes are real and stops firing on files that merely share a device. PR 24576's own testcases still pass, including the ././/script spelling that a name comparison alone would miss, because hosts with real inodes still take the inode path. Signed-off-by: Cole Munz <Munzzyy1@proton.me>
…er.exp
In gdb.rocm/watchpoint-at-end-of-shader.exp, we have:
...
[multi_line "Switching to \[^\r\n\]+(?=\r\n)" \
"" \
...
This expands to "Switching to \[^\r\n\]+(?=\r\n)\r\n".
The lookahead '(?=\r\n)' is superfluous (because it's followed by '\r\n'), so
drop it.
While we're at it, reduce escaping by using {}.
On ppc64-linux, with test-case gdb.python/py-selected-context.exp I run into:
...
(gdb) info inferiors^M
Num Description Connection Executable ^M
1 <null> ^M
* 2 <null> ^M
(gdb) FAIL: $exp: check inferior 2 was selected
...
In contrast, on x86_64-linux, I get:
...
(gdb) info inferiors^M
Num Description Connection Executable ^M
1 <null> ^M
* 2 <null> ^M
(gdb) PASS: $exp: check inferior 2 was selected
...
The output is identical, so it's surprising that there's a different
outcome.
The proc doing the check is:
...
proc check_inferior { inf testname } {
gdb_test "info inferiors" \
"\r\n\\*\\s+[string_to_regexp $inf]\\s+\[^\r\n\]*(?=\r\n)" \
$testname
}
...
The problem seems to be triggered by the lookahead part '(?=\r\n)': removing
it makes the test pass.
By switching on some debugging in gdb_test_multiple, we get this info:
...
Looking to match ""(?:\r\n\*\s+2\s+[^\r\n]*(?=\r\n))\r\n\(gdb\) $""
...
which shows that the lookahead '(?=\r\n)' is immediately followed by a '\r\n',
making the lookahead superfluous.
Still, the test should not fail. It fails due to an expect bug [1][2].
But, there's another problem with the regexp.
If we use the same proc to try to match inferior 1, we get a FAIL on both
setups:
...
(gdb) info inferiors^M
Num Description Connection Executable ^M
* 1 <null> ^M
2 <null> ^M
(gdb) FAIL: $exp: check inferior 1 was selected
...
The problem is that the regexp doesn't allow a line after the matching line.
Fix this this by appending '.*' to the regexp.
Doing so also has the effect that we no longer run into the expect problem.
While we're at it, rewrite the regexp to a more modern form, and drop the
unnecessary string_to_regexp:
...
[multi_line \
"" \
[subst_vars {[*]\s+$inf\s+[^\r\n]*(?=\r\n).*}]]
...
Tested on x86_64-linux and ppc64-linux.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=34471
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1143513
Fix two test-cases on ppc64-linux, where the .dot prefix used in the v1 ABI is causing a mismatch. Tested on ppc64-linux and x86_64-linux.
On ppc64-linux, with test-case gdb.tui/tailcall-msym.exp I ran into:
...
FAIL: $exp: status bar says main
...
The test-case:
- compiles the source to executable tailcall-msym
- gets some information about addresses
- recompiles the source to assembly
- adds some extra text to the assembly
- compiles the updated assembly into tailcall-msym-updated
The test-case source contains three functions: main, caller and callee.
The idea is that the updated executable has the same instructions, but an
additional function dumy_func at the location of the instructions of caller
after the call to callee.
On x86_64-linux, that looks like this:
...
000000000040111d <caller>:
40111d: 55 push %rbp
40111e: 48 89 e5 mov %rsp,%rbp
401121: e8 f0 ff ff ff call 401116 <callee>
0000000000401126 <dummy_func>:
401126: 8b 05 e8 2e 00 00 mov 0x2ee8(%rip),%eax
40112c: 83 c0 01 add $0x1,%eax
40112f: 89 05 df 2e 00 00 mov %eax,0x2edf(%rip)
401135: 8b 05 d9 2e 00 00 mov 0x2ed9(%rip),%eax
40113b: 83 c0 01 add $0x1,%eax
40113e: 89 05 d0 2e 00 00 mov %eax,0x2ed0(%rip)
401144: 90 nop
401145: 5d pop %rbp
401146: c3 ret
...
On ppc64-linux using the v1 ABI that doesn't work out (because of the complex
way functions are laid out in assembly), and instead caller stays the same,
but main is renamed to dummy_func:
...
(gdb) p dummy_func
$3 = {<text variable, no debug info>} 0x9b0 <dummy_func>
(gdb) p main
$4 = {<text variable, no debug info>} 0x9b0 <dummy_func>
(gdb)
...
There's a note in the test-case:
...
# Emit a new size for function 'caller', the assembler seems happy
# enough to just use this new length instead of the original length
# the compiler emitted.
#
# If this is ever a problem then we'll need to parse through the
# assembler file and remove the original .size directive.
...
and I tried that out manually, but it didn't help either.
Fix this by bailing out if not all four functions exist:
...
UNSUPPORTED: $exp: couldn't find function main
...
Likewise in gdb.base/tailcall-msym.exp.
Tested on ppc64-linux and x86_64-linux.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ROCgdb master → amd-staging conflict-free merge
Commits being merged: afa6db16e650...4ed310516eb7
This PR was opened automatically by the automerge workflow. Please validate CI, then merge.