With test-case gdb.base/nodebug.exp I run into:
...
gdb compile failed, gdb.base/nodebug.c: In function 'multf_noproto':
gdb.base/nodebug.c:63:1: warning: old-style function definition \
[-Wold-style-definition]
63 | multf_noproto (v1, v2)
| ^~~~~~~~~~~~~
...
Fix this using -std=c99.
Tested on x86_64-linux.
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
On x86_64-linux, with test-case gdb.rust/simple.exp I get:
...
(gdb) print sizeof(e)^M
$52 = 24^M
(gdb) PASS: $exp: print sizeof(e)
...
but on i686-linux I get instead:
...
(gdb) print sizeof(e)^M
$52 = 20^M
(gdb) FAIL: $exp: print sizeof(e)
...
The variable e for which we print the size:
...
let e = MoreComplicated::Two(73);
...
has type MoreComplicated which is defined like this:
...
pub struct HiBob {
pub field1: i32,
field2: u64,
}
...
enum MoreComplicated {
One,
Two(i32),
Three(HiBob),
Four{this: bool, is: u8, a: char, struct_: u64, variant: u32},
}
...
The answer to the question what the size of the enum should be seems to be
non-trivial [1][2], but AFAICT it doesn't seem to be illegal that the size can
differ between different platforms.
Fix this by accepting both 20 and 24 as valid size.
Tested on x86_64-linux and i686-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://doc.rust-lang.org/reference/types/enum.html
[2] https://doc.rust-lang.org/reference/type-layout.html#the-rust-representation
This commit allows GDB to make use of the file set with the 'file'
command when starting a new inferior on an extended-remote target.
There are however some restrictions.
If the user has used 'set remote exec-file', then this setting is
always used in preference to the file set with the 'file' command.
Similarly, if the qExecAndArgs packet has succeeded, and GDB knows
that the remote target has an executable set, then this will be used
in preference to the file set with the 'file' command; this preserves
GDB's existing behaviour. In effect, when GDB connects to the remote
target, the remote sets the 'remote exec-file' and this prevents GDB
from using the 'file' filename.
And, GDB can only use the file set with the 'file' command if it
believes that both GDB and the remote target will both be able to
access this file. This means that one of these is true:
+ the the remote_target::filesystem_is_local function returns
true (see the implementation of that function for details of when
this can happen). This means GDB and the remote target can see
the same file system, GDB can just use the current executable's
filename as is, or
+ the user has set the 'file' to something with a 'target:' prefix,
e.g. 'file target:/path/to/exec'. In this last case, GDB will use
the exec filename without the 'target:' prefix, this filename is,
by definition, something the remote target can see, or
+ the sysroot has been updated by the user and no longer contains a
'target:' prefix. In this case, if the 'file' filename is within
the sysroot, then it is assumed the remote will also be able to
see a file with the same filename. For example, if the sysroot is
'/aa/', and the current executable is '/aa/bb/cc', then GDB will
tell the remote to run '/bb/cc'. One common case here is when the
sysroot is set to the empty string, which is usually done when GDB
and the remote target can see the same filesystem, in this case
GDB will use the current executable's filename unmodified.
If one of these conditions is met, then GDB will use the current
executable's filename (with possible modifications as mentioned
above), when starting a new extended-remote inferior, in all other
cases, GDB will use the file name set with 'set remote exec-file'.
This change could be useful any time a user is running a remote target
on the same machine as GDB, but I am specifically thinking of the case
where GDB is using a tool other than gdbserver, e.g. valgrind, as this
saves one additional step that a user must remember. The current
steps to start valgrind with GDB, as given on the valgrind
website (https://valgrind.org/docs/manual/manual-core-adv.html) are:
$ gdb prog
(gdb) set remote exec-file prog
(gdb) set sysroot /
(gdb) target extended-remote | vgdb --multi --vargs -q
(gdb) start
With this GDB work, and once support for the qExecAndArgs packet is
added to valgrind, then the 'set remote exec-file' line can be dropped
from those instructions.
This commit also extends the 'show remote exec-file' command so that
GDB will display the automatic value that it plans to use. Here's an
example of the new output:
$ gdb -q /tmp/hello
Reading symbols from /tmp/hello...
(gdb) set sysroot
(gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
Remote debugging using | ./gdbserver/gdbserver --multi --once -
Remote debugging using stdio
(gdb) show remote exec-file
The remote exec-file is unset, using automatic value "/tmp/hello".
The last line shows the new output.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change the types to target_desc_up so it's not needed to `.release()`
them. This is similar to this review comment:
https: //inbox.sourceware.org/gdb-patches/87seeuak0z.fsf@tromey.com/
Change-Id: I45e0e77b00701aa979e8f7f15f397836b4e19849
Approved-By: Maciej W. Rozycki <macro@orcam.me.uk>
Tested-By: Maciej W. Rozycki <macro@orcam.me.uk>
A small tidy that allows other symbols or warnings to appear in nm
output, and works around the case problem of windows drive letters
by simply omitting the $srcdir match.
* testsuite/binutils-all/objcopy.exp (binary_symbol): Check
objcopy and nm return status. Don't repeat prune_warnings
already done in binutils_run. Match each symbol separately,
reporting which match failed on a failure. Don't match
$srcdir in implicit test.
With qemu supporting 64 bit now, add some code to determine the
register size of a hppa remote target.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Iffade4e02d758b9cb20c8f206e812bf3205518f7
On i686-linux (and likewise arm-linux), I run into:
...
(gdb) file str-chars^M
Reading symbols from str-chars...^M
warning: stabs debug information is not supported.^M
(No debugging symbols found in str-chars)^M
(gdb) delete breakpoints^M
...
Fix this by using fpc option -gw2.
Tested on i686-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
PR testsuite/33564
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33564
A review of an earlier version of this series pointed out some missing
_() invocations in symmisc.c. This fixes the ones I thought were
appropriate. In some spots I chose not to add them because the text
didn't seem like something that ought to be translated.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
While exploring a question I had about the DWARF indexer, I found I
wanted to see the CU index of each entry. This patch adds this
information.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I was looking at some "maint" output and noticed that symmisc.c could
apply styling in a few spots. This patch is the result.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Currently, the pre-commit check check-whitespace has verbose=true:
...
$ pre-commit run --all-files check-whitespace
check-whitespace........................................................Passed
- hook id: check-whitespace
- duration: 0.3s
$
...
That's not necessary, since:
- check-whitespace has no output if the check passes, and
- pre-commit shows the output anyway if the check fails.
Fix this by removing the verbose setting, getting us instead:
...
$ pre-commit run --all-files check-whitespace
check-whitespace........................................................Passed
$
...
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I ran the testsuite twice, once with target board unix, and once with target
board unix/-fPIE/-pie, compare the two sum files, and got for test-case
gdb.mi/mi-memory-changed.exp:
...
< PASS: $exp: set var *(unsigned int *) 0x4011b0 = 0xe5894855
---
> PASS: $exp: set var *(unsigned int *) 0x5555555551c3 = 0xe5894855
...
Fix this by dropping the concrete address from the test name:
...
PASS: $exp: set var *(unsigned int *) 0x${main_addr} = ${main_insn}
...
Tested on x86_64-linux.
I ran the testsuite twice, compare the two sum files, and got for test-case
gdb.arch/amd64-shadow-stack-corefile.exp:
...
3077c3077
< PASS: $exp: OS corefile: pl3_ssp contents from core file 0x7f7a38
3fffe0
---
> PASS: $exp: OS corefile: pl3_ssp contents from core file 0x7f179e
...
Fix this by dropping the address from the test name.
Tested on x86_64-linux.
As a non-private function, it shouldn't have a "_bfd_" prefix, but merely
a "bfd_" one. Hence commit 50efe229dd ("bfd/ELF: mark internal functions
hidden") also wrongly added ATTRIBUTE_HIDDEN to it.
It seems that glob patterns no longer work in the test suite, at least
on some host/dejagnu/shell combinations. In any case it is better
here not to create a single relax-7?.o file from the two source files,
but to create two separate objects for linking.
ld/
* testsuite/ld-h8300/relax-7.d: Replace the glob pattern with
multiple "source" options.
Signed-off-by: Jan Dubiec <jdx@o2.pl>
Addressing (an old) review comment suggesting this housekeeping item.
Use consistent naming style in libsframe. sframe_decoder_ctx objects
are named 'dctx', so use 'ectx' for sframe_encoder_ctx objects.
Make necessary changes in all the applicable declarations and definitions.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
With test-case gdb.trace/mi-trace-frame-collected.exp I run into:
...
gdb compile failed, gdb.trace/actions.c: In function 'main':
gdb.trace/actions.c:139:1: warning: old-style function definition \
[-Wold-style-definition]
139 | main (argc, argv, envp)
| ^~~~
...
Fix this by rewriting main into a prototyped function.
Tested on x86_64-linux.
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
Adjust the sanity checks for flip_fde workflow and optional trailing
section padding to account for the case of ihp->sfh_fdeoff != 0 or
ihp->sfh_freoff != total FDEs size.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
libsframe/
* sframe.c (flip_sframe): Fix checks in flip_fde to accommodate
cases when sfh_fdeoff != 0 or when SFrame FREs are placed after
a gap from SFrame FDEs.
In test-case gdb.base/callfuncs.exp I run into:
...
gdb compile failed, gdb.base/callfuncs.c: In function 't_func_values':
gdb.base/callfuncs.c:611:12: error: too many arguments to function \
'func_arg1'; expected 0, have 2
611 | return ((*func_arg1) (5,5) == (*func_val1) (5,5)
| ~^~~~~~~~~~~ ~
...
Fix this by using -std=c99.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
Update readelf to display the base symbol version as
Symbol table for image contains 5 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar@@
2: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1
3: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar@@VERS_1
4: 0000000000003000 0 OBJECT GLOBAL DEFAULT 10 foo@
instead of
Symbol table for image contains 5 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar
2: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1
3: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar@@VERS_1
4: 0000000000003000 0 OBJECT GLOBAL DEFAULT 10 foo
That is bar@@ and foo@ vs bar and foo.
binutils/
PR binutils/33599
* readelf.c (process_version_sections): Replace 0x8001 with
(VERSYM_HIDDEN | VERSYM_BASE).
(get_symbol_version_string): Likewise. Return "" for the base
version.
include/
PR binutils/33599
* elf/common.h (VERSYM_BASE): New.
ld/
PR binutils/33599
* testsuite/ld-elf/pr33599.d: New file.
* testsuite/ld-elf/pr33599.map: Likewise.
* testsuite/ld-elf/pr33599.s: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
I'm seeing this FAIL with the native-extended-gdbserver board:
(gdb) add-inferior^M
[New inferior 2]^M
Added inferior 2 on connection 1 (extended-remote localhost:2365)^M
(gdb) FAIL: gdb.python/py-parameter.exp: test_per_inferior_parameters: add-inferior
This is another case of add-inferior producing more output when
connected to a remote target. Adjust the regexp to accomodate it.
Change-Id: Ic5760ff66712c54b90b9debf379dcbf6e07f6eeb
I see this FAIL when running with the native-extended-gdbserver board:
Expecting: ^(-add-inferior[^M
]+)?(.*\^done,inferior="i2"[^M
]+[(]gdb[)] ^M
[ ]*)
-add-inferior^M
=thread-group-added,id="i2"^M
~"[New inferior 2]\n"^M
~"Added inferior 2 on connection 1 (extended-remote localhost:2345)\n"^M
^done,inferior="i2",connection={number="1",name="extended-remote"}^M
(gdb) ^M
FAIL: gdb.mi/set-show.exp: test_per_inferior_parameters: add inferior (unexpected output)
This is another case of the add-inferior command producing more output
when connected to a remote target. Adjust the regexp to accomodate it.
Change-Id: Ifa0590211fd75d4a01dff942c6bb810d5caf1257
We had a customer bug report which was eventually tracked down to
gdbserver not fully sending a target description to gdb. (This
presented as a timeout on the gdb side.)
The customer was using the WINAPI code, which does this:
# define write(fd, buf, len) send (fd, (char *) buf, len, 0)
In this setup, I think it's possible to have a partial write.
However, gdbserver does not account for this possibility, despite the
fact that write_prim documents this.
This patch attempts to fix the problem by always writing the full
buffer in write_prim. In this case the customer fixed their bug in a
different way, so we haven't actually tested this in the wild.
v2: Return bool from write_prim.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
Make the field private to make it clear it is never meant to change.
Pass its value through the constructor, and add a getter. The only
place that passes true is the signature_type constructor.
Change-Id: Ifb76bc015bca16696fd66cdf45c048b4ba713479
Approved-By: Tom Tromey <tom@tromey.com>
Except for the m_length field, that is already private and has a setter,
make the fields whose values are passed through the constructor private.
The idea is that their values should be constant throughout the life of
the object. Add some getters and update the callers.
I wasn't sure if making some bitfields public and some private would
change how they are packed, so I checked with "ptype/o", it does not.
Change-Id: I7087bebf69e44d16a36c1dd4d7edf9b8bf085343
Approved-By: Tom Tromey <tom@tromey.com>
I thought that this comment could be updated to clarify what this vector
holds and what it is used for.
Change-Id: I0e1968c8c6455b49aa156669c43ea8c436c59e45
Approved-By: Tom Tromey <tom@tromey.com>
This reverts commit 5e648fc6a0, since it
breaks the GDB build:
CXX elfread.o
/home/smarchi/src/binutils-gdb/gdb/elfread.c: In function ‘symfile_segment_data_up elf_symfile_segments(bfd*)’:
/home/smarchi/src/binutils-gdb/gdb/elfread.c:145:12: error: ‘is_debuginfo_file’ was not declared in this scope
145 | if (!is_debuginfo_file (abfd)
| ^~~~~~~~~~~~~~~~~
Change-Id: I180a9f6936365c365a853c7dae2af01f5207a84e
I see this failure:
$ make check TESTS="gdb.base/with.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
FAIL: gdb.base/with.exp: repeat: reinvoke with no previous command to relaunch
It seems like that failure has always been there and I didn't notice?
I'm not sure what is the intent of the test exactly. It sounds like it
is meant to test what happens when you use command "with language ada"
as the very first command of a GDB session? However, clean_restart and
gdb_load issue some commands before that test. The different between
the native-extended-gdbserver board and the other boards is: for other
boards, the previous command is a "file" command, which is a "no repeat"
command, which gives the expected error message. With the
native-extended-gdbserver board, the previous command is "set remote
exec-file", which is a repeatable command.
"Fix" it by making a "no repeat" command just before the test, so that
it works the same regardless of the target board.
Change-Id: I254faf196f49e9efd492fc9dd5f6ce7b96f72af7
Approved-By: Tom Tromey <tom@tromey.com>
C standard gnu23 introduces a new keyword 'thread_local'.
So, this variables must be renamed to avoid build errors.
Approved-By: Tom Tromey <tom@tromey.com>
Symbols defined in PIE should be bound locally, the same as -shared
-Bsymbolic.
Port x86 commit 4e0c91e454 ("Bind defined symbol locally in PIE")
change of relocate_section as well as linker tests to s390. Similar as
done for other architectures with the following commits:
- AArch64: ac33b731d2 ("[AArch64] Bind defined symbol locally in PIE")
- ARM: 1dcb9720d6 ("[ARM] Bind defined symbol locally in PIE")
- RISC-V: 39c7793ba8 ("RISC-V: Bind defined symbol locally in PIE")
- x86: 4e0c91e454 ("Bind defined symbol locally in PIE")
With this change symbols defined in an executable (i.e. PDE or PIE) are
bound locally, as they cannot be interposed. In the same way as symbols
defined in a shared library linked with -Bsymbolic are bound locally.
This also ensures that all defined symbols are bound locally in
static PIE.
Do not port the x86 change of check_relocs (now scan_relocs). None of
the linker tests where the change in condition triggers (e.g. bootstrap,
cdtest) produce different readelf -Wa output. The change appears to
affect accounting of space required for dynamic relocations. Instead of
accounting them in check_relocs and later filtering them away in
allocate_dynrelocs, they would not get accounted in the first place:
The change in the expression would only have an effect if the following
conditions are all met in addition to PIE: ALLOC, PC-relative
relocation, global symbol, not defined weak, and defined regular. In
this specific case the accounting of the PC relative relocation in
h->dyn_relocs would be skipped for PIE. But allocate_dynrelocs later
eliminates any PC-relative dynamic relocations if PIC (= PIE or shared
library) and SYMBOL_CALLS_LOCAL.
bfd/
PR ld/33141
* elf64-s390.c (elf_s390_relocate_section): Bind defined symbol
locally in PIE.
ld/testsuite/
PR ld/33141
* ld-s390/s390.exp: Add pr33141 tests.
* ld-s390/pr33141.rd: New file.
* ld-s390/pr33141a.s: Likewise.
* ld-s390/pr33141b.s: Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
