While working on target_waitstatus changes, I noticed a few places where
const target_waitstatus objects could be passed by reference instead of
by pointers. And in some cases, places where a target_waitstatus could
be passed as const, but was not. Convert them as much as possible.
Change-Id: Ied552d464be5d5b87489913b95f9720a5ad50c5a
I would like to print target_waitkind values in debug messages, so I
think that a target_waitkind-to-string function would be useful. While
at it, use it in target_waitstatus::to_string. This changes the output
of target_waitstatus::to_string a bit, but I think it is for the better.
The debug messages will show a string matching exactly the
target_waitkind enumerator (minus the TARGET_WAITKIND prefix).
As a convenience, make string_appendf return the same reference to
string it got as a parameter. This allows doing this:
return string_appendf (str, "foo");
... keeping the code concise.
Change-Id: I383dffc9c78614e7d0668b1516073905e798eef7
Make target_waitstatus_to_string a "to_string" method of
target_waitstatus, a bit like we have ptid_t::to_string already. This
will save a bit of typing.
Change-Id: Id261b7a09fa9fa3c738abac131c191a6f9c13905
If we always use the .option arch to call the riscv_update_subset, then
it is almost impossible that the input string will be NULL. Therefore,
just remove the redundant NULL pointer check in the riscv_update_subset.
bfd/
* elfxx-riscv.c (riscv_update_subset): Removed the redundant NULL
pointer check.
A build error on x86_64 with x32 abi was reported here (
https://sourceware.org/pipermail/gdb/2021-November/049787.html ):
...
gdb/nat/amd64-linux-siginfo.c:280:42: error: \
'struct compat_x32_siginfo_t::<unnamed union>::<unnamed>' has no member \
named 'si_addr_bnd'
280 | #define cpt_si_lower _sifields._sigfault.si_addr_bnd._lower
| ^~~~~~~~~~~
gdb/nat/amd64-linux-siginfo.c:337:38: note: in expansion of macro 'cpt_si_lower'
337 | to->cpt_si_lower = from_ptrace.cpt_si_lower;
| ^~~~~~~~~~~~
...
The problem is that code added in commit d3d7d1ba3b "[gdb/tdep] Handle
si_addr_bnd in compat_siginfo_from_siginfo" doesn't compile on an x86_64 x32
setup, because compat_x32_siginfo_t doesn't have the si_addr_bnd fields.
Fix this conservatively by disabling the code for x32.
Tested on x86_64-linux.
The architecture parser in riscv_update_subset shouldn't check (or access)
the pointer space which doesn't exist.
bfd/
pr 28610
* elfxx-riscv.c (riscv_update_subset): The architecture parser
shouldn't access the pointer space which doesn't exist.
I noticed a new gcc option -gdwarf64 and tried it out (using gcc 11.2.1).
With a test-case hello.c:
...
int
main (void)
{
printf ("hello\n");
return 0;
}
...
compiled like this:
...
$ gcc -g -gdwarf64 ~/hello.c
...
I ran into:
...
$ gdb -q -batch a.out
DW_FORM_line_strp pointing outside of .debug_line_str section \
[in module a.out]
...
Debugging gdb revealed that the string offset is:
...
(gdb) up
objfile=0x182ab70, str_offset=1378684502312,
form_name=0xeae9b5 "DW_FORM_line_strp")
at src/gdb/dwarf2/section.c:208
208 error (_("%s pointing outside of %s section [in module %s]"),
(gdb) p /x str_offset
$1 = 0x14100000128
(gdb)
...
which is read when parsing a .debug_line entry at 0x1e0.
Looking with readelf at the 0x1e0 entry, we have:
...
The Directory Table (offset 0x202, lines 2, columns 1):
Entry Name
0 (indirect line string, offset: 0x128): /data/gdb_versions/devel
1 (indirect line string, offset: 0x141): /home/vries
...
which in a hexdump looks like:
...
0x00000200 1f022801 00004101 00000201 1f020f02
...
What happens is the following:
- readelf interprets the DW_FORM_line_strp reference to .debug_line_str as
a 4 byte value, and sees entries 0x00000128 and 0x00000141.
- gdb instead interprets it as an 8 byte value, and sees as first entry
0x0000014100000128, which is too big so it bails out.
AFAIU, gdb is wrong. It assumes DW_FORM_line_strp is 8 bytes on the basis
that the corresponding CU is 64-bit DWARF. However, the .debug_line
contribution has it's own initial_length field, and encodes there that it's
32-bit DWARF.
Fix this by using the correct offset size for DW_FORM_line_strp references
in .debug_line.
Note: the described test-case does trigger this complaint (both with and
without this patch):
...
$ gdb -q -batch -iex "set complaints 10" a.out
During symbol reading: intermixed 32-bit and 64-bit DWARF sections
...
The reason that the CU has 64-bit dwarf is because -gdwarf64 was passed to
gcc. The reason that the .debug_line entry has 32-bit dwarf is because that's
what gas generates. Perhaps this is complaint-worthy, but I don't think it
is wrong.
Tested on x86_64-linux, using native and target board dwarf64.exp.
The v5 section version for .debug_line has:
- two new fields address_size and segment_selector_size
- a different way to encode the directory and filename tables.
Add support for this in the dwarf assembler.
For now, make the v5 directory and filename tables work with the v4 type of
specification in the test-cases by adding duplicate entries at position 0.
This will need to be properly fixed with an intrusive fix that changes how
directory and filename entries are specified in the test-cases, f.i:
...
set diridx [include_dir "${srcdir}/${subdir}"]
set fileidx [file_name "$srcfile" $diridx]
...
Tested on x86_64-linux.
Rather than generate dwarf immediately in procs include_dir and file_name,
postpone generation and store the data in variables. Then handle the
generation in a new proc _line_finalize_header.
Tested on x86-64-linux.
The .debug_line header got a new field in v4:
maximum_operations_per_instruction.
Generate this field in the dwarf assembler, for now hardcoding the value to 1,
meaning non-VLIW.
Tested on x86_64-linux.
Currently, for each MACRO_AT_range or MACRO_AT_func in dwarf assembly the
following is done:
- $srcdir/$subdir/$srcfile is compiled to an executable using
flags "debug"
- a new gdb instance is started
- the new executable is loaded.
This is inefficient, because the executable is identical within the same
Dwarf::assemble call.
Share the gdb instance in the same Dwarf::assemble invocation, which speeds
up a make check with RUNTESTFLAGS like this to catch all dwarf assembly
test-cases:
...
rtf=$(echo $(cd src/gdb/testsuite; find gdb.* -type f -name "*.exp" \
| xargs grep -l Dwarf::assemble))
...
from:
...
real 1m39.916s
user 1m25.668s
sys 0m21.377s
...
to:
...
real 1m29.512s
user 1m17.316s
sys 0m19.100s
...
Tested on x86_64-linux.
When running the testsuite I have the following:
Running .../gdb/testsuite/gdb.base/catch-signal.exp ...
DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue
DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue
DUPLICATE: gdb.base/catch-signal.exp: 1: continue
DUPLICATE: gdb.base/catch-signal.exp: 1: continue
DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue
DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue
This patch removes DUPLICATE in gdb.base/catch-signal.exp by explicitly
giving names to the offending 'gdb_test "continue"' statements to make
them distinct.
Tested on x86_64-linux.
The v850 testsuite code has been testing the $opt variable, but this
was never actually set anywhere globally or v850-specific. Instead,
this was a random variable leaking out of the sh testsuite code. As
far as I can tell, it has always been this way. That means the code
only ever tested the v850 cpu target (which is the default).
This failure can be easily seen in practice by running the v850 code
in isolation and seeing it crash:
$ runtest v850/allinsns.exp
...
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../sim/testsuite/config/default.exp as tool-and-target-specific interface file.
WARNING: Assuming target board is the local machine (which is probably wrong).
You may need to set your DEJAGNU environment variable.
Running ../../../sim/testsuite/v850/allinsns.exp ...
ERROR: tcl error sourcing ../../../sim/testsuite/v850/allinsns.exp.
ERROR: tcl error code TCL LOOKUP VARNAME opt
ERROR: can't read "opt": no such variable
while executing
"switch -regexp -- $opt {
Backing up a bit, the reason for this logic in the first place is
because the common sim testsuite code makes an assumption about the
assembler options with cpu_option -- the option and its value are
always separated by an =. This is not the case with v850. So tweak
the core sim logic a bit to support omitting the = so that we can
switch v850 to the standard all_machs setting and avoid opt entirely.
The upstream GCC tester has showed spurious execution failures on the
H8 target for the H8/SX multilibs. I suspected memory corruption or an
uninitialized variable early as the same binary would sometimes work and
sometimes it got the wrong result. Worse yet, the point where the test
determined it was getting the wrong result would change.
Because it only happened on the H8/SX variant I was able to zero in on
the "mova" support and the "short form" of those instructions in particular.
As the code stands it checks if code->op3.type == 0 to try and identify cases
where op3 wasn't filled in and thus we've got the short form of the mova
instruction.
But for the short-form of those instructions we never set any of the "op3"
data structure. We get whatever was lying around -- it's usually zero and
thus things usually work, but if the stale data was nonzero, then we'd
fail to recognize the instruction as a short-form and fail to set up the
various fields appropriately.
I initially initialized the op3.type field to zero, but didn't like that
because it was inconsistent with how other operands were initialized.
Bringing consistency meant using -1 as the initializer value and adjusting
the check for short form mova appropriately.
I've had this in the upstream GCC tester for perhaps a year at this point
and haven't seen any of the intermittent failures again.
When building with -std=c++11 and -D_GLIBCXX_DEBUG=1, we get some errors
like:
CXX unittests/array-view-selftests.o
In file included from /home/smarchi/src/binutils-gdb/gdb/utils.h:25,
from /home/smarchi/src/binutils-gdb/gdb/defs.h:630,
from /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:20:
/home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h: In instantiation of constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int:
/home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:532:29: required from here
/home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:192:3: error: body of constexpr function constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int not a return-statement
192 | }
| ^
This is because constexpr functions in c++11 can only consist of a
single return statement, so we can't have the gdb_assert in there. Make
the gdb_assert presence conditional to the __cplusplus version, to
enable it only for c++14 and later.
Change-Id: I2ac33f7b4bd1765ddc3ac8d07445b16ac1f340f0
When building gdb with g++ 4.8.5, I ran into:
...
ld: source-cache.o: in function `source_cache::ensure(symtab*)':
source-cache.c:207: undefined reference to \
srchilite::SourceHighlight::SourceHighlight(std::string const&)
...
[ I configured gdb without explicit settings related to source-highlight, so
we're excercising the enable_source_highlight=auto scenario. ]
The problem is that:
- the source-highlight library is build with system compiler
g++ 7.5.0 which uses the new libstdc++ library abi (see
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html )
- gdb is build using g++ 4.8.5 which uses the old abi.
[ There's a compatibility macro _GLIBCXX_USE_CXX11_ABI, but that doesn't work
for this case. Instead, it enables the opposite case where the
source-highlight library is build with g++ 4.8.5 and gdb is build with
g++ 7.5.0. ]
Fix this by checking whether the source-highlight library is usable during
configuration.
In the enable_source_highlight=auto scenario, this allows the build to skip
the unusable library and finish successfully.
In the enable_source_highlight=yes scenario, this allows the build to error
out earlier.
Tested on x86_64-linux.
This comment was long time ago associated to the function
"xcoff_build_ldsyms" which have since been replaced by
"xcoff_build_ldsym".
* xcofflink.c: Remove wrong comment.
On OBS I ran into:
...
PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:81 (set breakpoint)
UNRESOLVED: gdb.mi/mi-var-cp.exp: unable to start target
...
followed by 81 FAILs and two more UNRESOLVEDs.
I didn't manage to reproduce this, but I did notice that the initial
problem causing the UNRESOLVED caused all subsequent UNRESOLVEDs and FAILs.
I emulated the problem by commenting out the send_gdb "run\n" in
mi_run_cmd_full.
Fix this by:
- handling mi_run_cmd failure in mi_get_inline_test
- handling mi_run_inline_test failure in gdb.mi/mi-var-cp.exp, and
other test-cases using mi_get_inline_test
Tested on x86_64-linux.
When running test-case gdb.dwarf2/loc-sec-offset.exp with target board -m32,
I run into:
...
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector -m32 \
-fdiagnostics-color=never -c -o loc-sec-offset-dw641.o \
loc-sec-offset-dw64.S^M
as: loc-sec-offset-dw641.o: unsupported relocation type: 0x1^M
loc-sec-offset-dw64.S: Assembler messages:^M
loc-sec-offset-dw64.S:29: Error: cannot represent relocation type \
BFD_RELOC_64^M
...
Looking at line 29, we have:
...
.8byte .Labbrev1_begin /* Abbrevs */
...
It would be nice if the assembler could handle this somehow. But I guess
it's not unreasonable that an assembler for a 32-bit architecture will object
to handling 64-bit labels.
Instead, work around this in the dwarf assembler by emitting:
...
.4byte .Labbrev1_begin /* Abbrevs (lsw) */
.4byte 0 /* Abbrevs (msw) */
...
Tested on x86_64-linux with target board unix/-m32.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28383
On OBS I ran into a failure in test-case gdb.threads/thread-specific-bp.exp:
...
(gdb) PASS: gdb.threads/thread-specific-bp.exp: non-stop: continue to end
info breakpoint^M
Num Type Disp Enb Address What^M
1 breakpoint keep y 0x0000555555555167 in main at $src:36^M
breakpoint already hit 1 time^M
2 breakpoint keep y 0x0000555555555151 in start at $src:23^M
breakpoint already hit 1 time^M
3 breakpoint keep y 0x0000555555555167 in main at $src:36 thread 2^M
stop only in thread 2^M
4 breakpoint keep y 0x000055555555515c in end at $src:29^M
breakpoint already hit 1 time^M
(gdb) [Thread 0x7ffff7db1640 (LWP 19984) exited]^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
FAIL: gdb.threads/thread-specific-bp.exp: non-stop: \
thread-specific breakpoint was deleted (timeout)
...
Fix this by waiting for the "[Thread 0x7ffff7db1640 (LWP 19984) exited]"
message before issuing the "info breakpoint command".
Tested on x86_64-linux.
This commit supplements whatis and ptype command tests for print of
const-volatile qualifiers.
gdb/testsuite/ChangeLog:
2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
* gdb.cp/ptype-cv-cp.cc: New const and volatile typedef
variables.
* gdb.cp/ptype-cv-cp.exp: Add new tests.
Make ptype print const/volatile qualifiers when template or typedef
attributes are substituted.
For a programm like
~~~
template<typename DataT>
class Cfoo
{
typedef float myfloat;
public:
DataT me0;
const DataT me1=1;
const myfloat me2=2.0;
};
int main()
{
Cfoo<int> cfoo;
return 0;
}
~~~
gdb outputs the following type for cfoo's attributes:
~~~
(gdb) b 14
Breakpoint 1 at 0x1170: file tmp.cc, line 14.
(gdb) run
Starting program: /tmp
Breakpoint 1, main () at tmp.cc:14
14 return 0;
(gdb) ptype cfoo
type = class Cfoo<int> [with DataT = int] {
public:
DataT me0;
DataT me1;
myfloat me2;
private:
typedef float myfloat;
}
~~~
The cv qualifiers (const in this case) are ignored for me1 and me2.
After:
~~~
(gdb) ptype cfoo
type = class Cfoo<int> [with DataT = int] {
public:
DataT me0;
const DataT me1;
const myfloat me2;
private:
typedef float myfloat;
}
~~~
gdb/ChangeLog:
2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
* gdb/c-typeprint.c: Print cv qualifiers in case of parameter
substitution.
gdb/testsuite/ChangeLog:
2021-11-16 Christina Schimpe <christina.schimpe@intel.com>
* gdb.cp/templates.cc: New template class Cfoo with const,
template, typdef and integer attributes.
* gdb.cp/templates.exp: Add new test using ptype and ptype/r
commmands for template class CFoo.
https://github.com/riscv/riscv-asm-manual/pull/67
Format:
.option arch, +<extension><version>, ...
.option arch, -<extension>
.option arch, =<ISA string>
The new direcitve is used to enable/disable extensions for the specific
code region. For example,
.attribute arch, "rv64ic" # arch = rv64i2p0_c2p0
.option push
.option arch, +d2p0, -c # arch = rv64i2p0_f2p0_d2p0, f is added implied
.option arch, =rv32gc # arch = rv32i2p0_m2p0_a2p0_f2p0_d2p0_c2p0
.option pop # arch = rv64i2p0_c2p0
Note that,
1. ".option rvc/norvc" have the same behavior as ".option arch +c/-c".
2. ".option arch -i" is illegal, since we cannot remove base i extension.
3. If arch=rv64i2p0, then ".option arch, +i3p0" will update the i's version
from 2.0 to 3.0.
4. If arch=rv64i3p0, then ".option arch, +i" will update the i's version
from 2.0 to the default one according to the chosen isa spec.
bfd/
* elfxx-riscv.c (riscv_add_subset): If the subset is already added,
and the new versions are not RISCV_UNKNOWN_VERSION, then update the
versions to the subset list.
(riscv_copy_subset): New function. Copy the subset from list.
(riscv_copy_subset_list): New function. Return the new copyed list.
(riscv_update_subset): Updated to make .option arch directives workable.
* elfxx-riscv.h: Updated.
gas/
* config/tc-riscv.c (riscv_subsets): Defined as a pointer.
(riscv_rps_as): Init the subset_list to NULL, we will set it later
once riscv_opts_stack is created or updated.
(struct riscv_option_stack, riscv_opts_stack): Moved forward.
(riscv_set_arch): Updated.
(s_riscv_option): Support new .option arch directive, to add, remove
or update subsets for the specific code region.
(riscv_write_out_attrs): Updated.
* doc/c-riscv.texi: Added document for new .option arch directive.
* testsuite/gas/riscv/option-arch-01a.d: New testcase.
* testsuite/gas/riscv/option-arch-01b.d: Likewise.
* testsuite/gas/riscv/option-arch-01.s: Likewise..
* testsuite/gas/riscv/option-arch-02.d: Likewise.
* testsuite/gas/riscv/option-arch-02.s: Likewise.
* testsuite/gas/riscv/option-arch-fail.d: Likewise.
* testsuite/gas/riscv/option-arch-fail.l: Likewise.
* testsuite/gas/riscv/option-arch-fail.s: Likewise.
On hppa*-hp-hpux* run_dump_test edits the test file, adjusting .comm
directives to suit those target's unusual syntax. Thus gas is passed
a temporary file name.
* testsuite/gas/all/multibyte1.l: Ignore file name.
This is the original discussion,
https://github.com/riscv/riscv-elf-psabi-doc/pull/190
And here is the glibc part,
https://sourceware.org/pipermail/libc-alpha/2021-August/129931.html
For binutils part, we need to support a new direcitve: .variant_cc.
The function symbol marked by .variant_cc means it need to be resolved
directly without resolver for dynamic linker. We also add a new dynamic
entry, STO_RISCV_VARIANT_CC, to indicate there are symbols with the
special attribute in the dynamic symbol table of the object.
I heard that llvm already have supported this in their mainline, so
I think it's time to commit this.
bfd/
* elfnn-riscv.c (riscv_elf_link_hash_table): Added variant_cc
flag. It is used to check if relocations for variant CC symbols
may be present.
(allocate_dynrelocs): If the symbol has STO_RISCV_VARIANT_CC
flag, then raise the variant_cc flag of riscv_elf_link_hash_table.
(riscv_elf_size_dynamic_sections): Added dynamic entry for
variant_cc.
(riscv_elf_merge_symbol_attribute): New function, used to merge
non-visibility st_other attributes, including STO_RISCV_VARIANT_CC.
binutils/
* readelf.c (get_riscv_dynamic_type): New function.
(get_dynamic_type): Called get_riscv_dynamic_type for riscv targets.
(get_riscv_symbol_other): New function.
(get_symbol_other): Called get_riscv_symbol_other for riscv targets.
gas/
* config/tc-riscv.c (s_variant_cc): Marked symbol that it follows a
variant CC convention.
(riscv_elf_copy_symbol_attributes): Same as elf_copy_symbol_attributes,
but without copying st_other. If a function symbol has special st_other
value set via directives, then attaching an IFUNC resolver to that symbol
should not override the st_other setting.
(riscv_pseudo_table): Support variant_cc diretive.
* config/tc-riscv.h (OBJ_COPY_SYMBOL_ATTRIBUTES): Defined.
* testsuite/gas/riscv/variant_cc-set.d: New testcase.
* testsuite/gas/riscv/variant_cc-set.s: Likewise.
* testsuite/gas/riscv/variant_cc.d: Likewise.
* testsuite/gas/riscv/variant_cc.s: Likewise.
include/
* elf/riscv.h (DT_RISCV_VARIANT_CC): Defined to (DT_LOPROC + 1).
(STO_RISCV_VARIANT_CC): Defined to 0x80.
ld/
* testsuite/ld-riscv-elf/variant_cc-1.s: New testcase.
* testsuite/ld-riscv-elf/variant_cc-2.s: Likewise.
* testsuite/ld-riscv-elf/variant_cc-now.d: Likewise.
* testsuite/ld-riscv-elf/variant_cc-r.d: Likewise.
* testsuite/ld-riscv-elf/variant_cc-shared.d: Likewise.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
Instead of always using target_alias as a prefix on the name, use
program_transform_name instead so that the library is scoped in the
same way as the run program.
Without this commit, doing...
make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" \
TESTS="gdb.base/dprintf-execution-x-script.exp"
...will show one failure.
Here's a snippet from gdb.log showing the circumstances - I've trimmed
the paths for readability:
builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 -iex set width 0 -iex set auto-connect-native-target off -iex set sysroot -ex set height unlimited -x testsuite/gdb.base/dprintf-execution-x-script.gdb --args testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script
...
Reading symbols from testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script...
Dprintf 1 at 0x40116e: file testsuite/gdb.base/dprintf-execution-x-script.c, line 38.
Breakpoint 2 at 0x40113a: file testsuite/gdb.base/dprintf-execution-x-script.c, line 26.
testsuite/gdb.base/dprintf-execution-x-script.gdb:21: Error in sourced command file:
Don't know how to run. Try "help target".
(gdb) FAIL: gdb.base/dprintf-execution-x-script.exp: load and run script with -x
...
GNU gdb (GDB) 12.0.50.20211118-git
Copyright (C) 2021 Free Software Foundation, Inc.
...
(gdb) set height 0
(gdb) set width 0
(gdb) builtin_spawn gdbserver/gdbserver --once --multi localhost:2346
Listening on port 2346
target extended-remote localhost:2346
Remote debugging using localhost:2346
...
[Tests after this point will pass.]
Note that the command which spawns gdb prevents the gdb script from
using the native target via "-iex set auto-connect-native-target off".
Moreover, the script in question contains a "run" command, so GDB
doesn't know how to run (since it's prevented from using the native
target and no alternate "target" command has been issued. But, once
GDB finishes starting up, the test will spawn a gdbserver and then
connect to it. The other (two) tests after this point both pass.
I've fixed this by using gdb_test_multiple instead of gdb_test.
When a "Don't know how to run message" is received, the test is
unsupported.
I've also added a comment explaining the reason for needing to check
for "Don't know how to run" despite bailing out at the top of the test
via:
if ![target_can_use_run_cmd] {
return 0
}
When building with g++ 4.8, I get:
CXX unittests/array-view-selftests.o
/home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:123:42: error: expected 'class' before 'Container'
template<template<typename ...> typename Container>
^
I am no C++ template expert, but it looks like if I change "typename" for
"class", as the compiler kind of suggests, the code compiles.
Change-Id: I9c3edd29fb2b190069f0ce0dbf3bc3604d175f48
When building with g++ 4.8, I get:
CXX ia64-tdep.o
/home/smarchi/src/binutils-gdb/gdb/ia64-tdep.c:3862:1: error: could not convert '{ia64_allocate_new_rse_frame, ia64_store_argument_in_slot, ia64_set_function_addr}' from '<brace
-enclosed initializer list>' to 'const ia64_infcall_ops'
};
^
This happens since commit 345bd07cce ("gdb: fix gdbarch_tdep ODR
violation"), which added default values for ia64_infcall_ops fields. It
looks like g++ 4.8 doesn't like initializing the ia64_infcall_ops object
using the brace-enclosed initializer list when the ia64_infcall_ops
fields are assigned default values.
Later compilers don't have a problem with that, so I suppose that the
code is correct, but still, change it to make gcc 4.8 happy. Don't
initialize the fields of ia64_infcall_ops directly, instead
default-initialize ia64_gdbarch_tdep::infcall_ops.
Change-Id: I35e3a61abd7b7bbcafe6cb207078c738c5266d76
The contents of rs6000-tdep.h (AIX_TEXT_SEGMENT_BASE) is AIX-specific,
so I thought that this file should be named rs6000-aix-tdep.h. But
there's already a rs6000-aix-tdep.h, so then I though
AIX_TEXT_SEGMENT_BASE should simply be moved there, and rs6000-tdep.h
deleted. But then I realized that AIX_TEXT_SEGMENT_BASE is only used in
rs6000-aix-tdep.c, so move it to the beginning of that file.
Change-Id: Ia212c6fae202f31aedb46575821cd642beeda7a3
This file seems to be AIX-specific, according to its contents and
configure.nat. Rename it to rs6000-aix-nat.c, to make that clear (and
to follow the convention).
Change-Id: Ib418dddc6b79b2e28f64431121742b5e87f5f4f5
The documentation for the examining memory command x contains an example:
...
You can also specify a negative repeat count to examine memory backward from
the given address. For example, 'x/-3uh 0x54320' prints three halfwords (h)
at 0x54314, 0x54328, and 0x5431c.
...
The 0x54328 looks like a typo, which was intended to be 0x54318.
But the series uses a 4-byte distance, while the halfword size used in the
command means a 2-byte distance, so the series should be:
...
0x5431a, 0x5431c, and 0x5431e.
...
Fix this by updating the addresses in the example accordingly.
Reported here ( https://sourceware.org/pipermail/gdb/2021-November/049784.html
).
* as.c (parse_args): Add support for --multibyte-handling.
* as.h (multibyte_handling): Declare.
* app.c (scan_for_multibyte_characters): New function.
(do_scrub_chars): Call the new function if multibyte warning is
enabled.
* input-scrub,c (input_scrub_next_buffer): Call the multibyte
scanning function if multibyte warnings are enabled.
* symbols.c (struct symbol_flags): Add multibyte_warned bit.
(symbol_init): Call the multibyte scanning function if multibyte
symbol warnings are enabled.
(S_SET_SEGMENT): Likewise.
* NEWS: Mention the new feature.
* doc/as.texi: Document the new feature.
* testsuite/gas/all/multibyte.s: New test source file.
* testsuite/gas/all/multibyte1.d: New test driver file.
* testsuite/gas/all/multibyte1.l: New test expected output.
* testsuite/gas/all/multibyte2.d: New test driver file.
* testsuite/gas/all/multibyte2.l: New test expected output.
* testsuite/gas/all/gas.exp: Run the new tests.
Commit 345bd07cce ("gdb: fix gdbarch_tdep ODR violation") made a bunch
of files define a *_gdbarch_tdep class that inherits from a gdbarch_tdep
base. But some of these files don't include gdbarch.h, where
gdbarch_tdep is defined. This may cause build errors if gdbarch.h isn't
already included by chance by some other header file. Avoid this by
making them include gdbarch.h.
Change-Id: If433d302007e274daa4f656cfc94f769cf1aa68a
Change gdb_assert_not_reached to accept a format string plus
corresponding arguments. This allows giving more precise messages.
Because the format string passed by the caller is prepended with a "%s:"
to add the function name, the callers can no longer pass a translated
string (`_(...)`). Make the gdb_assert_not_reached include the _(),
just like the gdb_assert_fail macro just above.
Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7
Remove check_continue "execve" from Proc test_catch_syscall_execve.
The check_continue proceedure checs that the command, execve, starts and
checks for the return from the command. The execve command starts a new
program and thus the return from the command causing the test to fail.
The call to proc check_continue "execve" is removed and replaced with
just the call to check_call_to_syscall "execve" to verify the command
executed. The next test in proc test_catch_syscall_execve verifies that
the new program started and hit the break point in main.
Update the check for the PowerPC architecture. Power Little Endian systems
include "le" in the name. The istarget "power64-*-linux*" check fails to
match LE sytems. The expected string is updated to capture both Big Endian
and Little Endian systems. Power 10 LE istarget prints as:
powerpc64le-unknown-linux-gnu.
This patch fixes three failures and the error:
ERROR: can't read "arch1": no such variable
Patch tested on Power 10 ppc64le GNU/Linux platform.
This patch fixes eight test failures on PowerPC for the test
gdb.base/break-interp.exp. The patch adds a funtion and registers it to
setup the displaced stepping for ppc-linux platform. The patch moves the
struct ppc_inferior_data to the ppc-tdep.h include file to make it visible
to the ppc-linux-tdep.c and rs6000-tdep.c files. Additionally the function
get_ppc_per_inferior is made external in ppc-tdep.h to make it visible in
both files.
Tested on Power 10 ppc64le-linux with no regressions.
The test complains of duplicate tests.
DUPLICATE: gdb.arch/ppc-longdouble.exp: continue to breakpoint: return
The do_test calls gdb_continue_to_breakpoint "return". The duplicates
are the result of calling do_test three times with different arguments.
This patch fixes the duplicate tests by adding $name to the
gdb_continue_to_breakpoint argument.
Patch tested on Power 10 ppc64le GNU/Linux, no duplicate tests reported,
no new regression errors.
