Without this, a "make all-sim" without the equivalent of
libreadline-dev installed on the build system, won't
properly pick up the in-tree readline build, and you'll see:
mkdir -p -- ./sim
Configuring in ./sim
configure: creating cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... cris-axis-elf
checking for x86_64-pc-linux-gnu-gcc... gcc
checking whether the C compiler works... yes
...
checking for library containing tgetent... -ltermcap
checking for readline in -lreadline... no
configure: error: the required "readline" library is missing
make[1]: *** [Makefile:11188: configure-sim] Error 1
make[1]: Leaving directory '/home/hp/sim/b'
The sim dependency on readline is apparently (nominally)
valid as there's a readline call in sim/erc32/sis.c.
2022-02-21 Hans-Peter Nilsson <hp@axis.com>
* Makefile.def (dependencies): Make configure-sim depend on
all-readline.
Remove a stray trailing backslash from `test-integer' in settings.exp.
It is harmless as only white space follows in the next line before the
closing brace, so it merely swallows the newline character, but it may
look confusing to the reader.
The idea here is to replace expressions like v + 1 + 1 + 1 with v + 3.
* dwarf2dbg.c (set_or_check_view): Remove useless assertion.
Resolve multiple view increments.
* testsuite/gas/elf/dwarf2-18.d: Don't xfail mep.
* symbol.c (struct symbol_flags): Add forward_resolved.
(symbol_entry_find): Update needle initialisation.
(symbol_clone_if_forward_ref): Do no work when forward_resolved
is already set. Set forward_resolved.
If an auto-load script cannot be found and objfile is a separate
debuginfo whose filename does not match the name found in the parent
file's .gnu_debuglink section, then repeat the search using the
parent's filename where the last component is replaced with the
.gnu_debuglink name.
For example if the parent's filename is "/usr/lib/libxyz.so" and the
name in its .gnu_debuglink section is "libxyz.so.debug", then
if no auto-load script is otherwise found the search will be
repeated with the filename "/usr/lib/libxyz.so.debug".
This helps gdb locate auto-load scripts when debuginfo files do not have
the expected filename, such as when they are aquired from debuginfod.
Source files downloaded from debuginfod currently use their original DWARF
filename as their "fullname". This causes a mismatch between the fullname
and the actual location of the source file in the debuginfod client cache.
MI consumers such as VSCode will fail to open debuginfod-downloaded
source files due to this. Also 'info source' will fail to include the
true paths of these files.
To fix this, use the debuginfod cache path as the fullname for debuginfod-
downloaded source files.
Fix for PR gdb/20684. When invoking MI commands with --thread and/or
--frame, the user selected thread and frame was not preserved:
(gdb)
info thread
&"info thread\n"
~" Id Target Id Frame \n"
~"* 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
~" 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
^done
(gdb)
info frame
&"info frame\n"
~"Stack level 0, frame at 0x7fffffffdf90:\n"
~" rip = 0x555555555207 in main (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60); saved rip = 0x7ffff7c5709b\n"
~" source language c.\n"
~" Arglist at 0x7fffffffdf80, args: \n"
~" Locals at 0x7fffffffdf80, Previous frame's sp is 0x7fffffffdf90\n"
~" Saved registers:\n "
~" rbp at 0x7fffffffdf80, rip at 0x7fffffffdf88\n"
^done
(gdb)
-stack-info-depth --thread 3
^done,depth="4"
(gdb)
info thread
&"info thread\n"
~" Id Target Id Frame \n"
~" 1 Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
~" 2 Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
~"* 3 Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
^done
(gdb)
info frame
&"info frame\n"
~"Stack level 0, frame at 0x7ffff742dee0:\n"
~" rip = 0x555555555169 in child_sub_function (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30); saved rip = 0x555555555188\n"
~" called by frame at 0x7ffff742df00\n"
~" source language c.\n"
~" Arglist at 0x7ffff742ded0, args: \n"
~" Locals at 0x7ffff742ded0, Previous frame's sp is 0x7ffff742dee0\n"
~" Saved registers:\n "
~" rbp at 0x7ffff742ded0, rip at 0x7ffff742ded8\n"
^done
(gdb)
This caused problems for frontends that provide access to CLI because UI
may silently change the context for CLI commands (as demonstrated above).
This commit fixes the problem by restoring thread and frame in
mi_cmd_execute (). With this change, there are only two GDB/MI commands
that can change user selected context: -thread-select and -stack-select-frame.
This allows us to remove all and rather complicated logic of notifying
about user selected context change from mi_execute_command (), leaving it
to these two commands themselves to notify.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20684
There's an interesting property of the 'char' type in C and C++, the
three types 'char', 'unsigned char', and 'signed char', are all
considered distinct.
In contrast, and 'int' is signed by default, and so 'int' and 'signed
int' are considered the same type.
This commit adds a test to ensure that this edge case is visible to a
user from Python.
It is worth noting that for any particular compiler implementation (or
the flags a compiler was invoked with), a 'char' will be either signed
or unsigned; it has to be one or the other, and a user can access this
information by using the Type.is_signed property. However, for
something like function overload resolution, the 'char' type is
considered distinct from the signed and unsigned variants.
There's no change to GDB with this commit, this is just adding a new
test to guard some existing functionality.
Add a new read-only property, Type.is_signed, which is True for signed
types, and False otherwise.
This property should only be read on types for which Type.is_scalar is
true, attempting to read this property for non-scalar types will raise
a ValueError.
I chose 'is_signed' rather than 'is_unsigned' in order to match the
existing Architecture.integer_type method, which takes a 'signed'
parameter. As far as I could find, that was the only existing
signed/unsigned selector in the Python API, so it seemed reasonable to
stay consistent.
Following on from the previous commit, where the -add-inferior command
now uses the same connection as the current inferior, this commit adds
a --no-connection option to -add-inferior.
This new option matches the existing option of the same name for the
CLI version of add-inferior; the new inferior is created with no
connection.
I've added a new 'connection' field to the MI output of -add-inferior,
which includes the connection number and short name. I haven't
included the longer description field, this is the MI after all. My
expectation would be that if the frontend wanted to display all the
connection details then this would be looked up from 'info
connection' (or the MI equivalent if/when such a command is added).
The existing -add-inferior tests are updated, as are the docs.
Prior to the multi-target support commit:
commit 5b6d1e4fa4
Date: Fri Jan 10 20:06:08 2020 +0000
Multi-target support
When a new inferior was added using the MI -add-inferior command, the
new inferior would be using the same target as all the other
inferiors. This makes sense, GDB only supported a single target stack
at a time.
After the above commit, each inferior has its own target stack.
To maintain backward compatibility, for the CLI add-inferior command,
when a new inferior is added the above commit has the new inferior
inherit a copy of the target stack from the current inferior.
Unfortunately, this same backward compatibility is missing for the MI.
This commit fixes this oversight.
Now, when the -add-inferior MI command is used, the new inferior will
inherit a copy of the target stack from the current inferior.
GDB has a dbx emulation mode that adds a few aliases and helper
commands. This mode is barely documented and is very superficial
besides. I suspect it is rarely used, and I would like to propose
deprecating it for GDB 12, and then removing it in GDB 13.
infrun.c:handle_one calls find_inferior_ptid unnecessarily, since we
already have a thread pointer handy, and the thread has a pointer to
the inferior. This commit removes the unnecessary lookup.
Change-Id: I2ae18601dd75346c6c91068e9a4f9a6484fb3339
ada_print_floating rewrites a floating-point string representation to
conform to Ada syntax. However, if you managed to get a floating
point error, you might see:
(gdb) print whatever
$2 = <invalid float valu.0e>
What's happening here is that ada_print_floating doesn't recognize
this error case, and proceeds to modify the error text.
This patch fixes this problem.
Sometimes it is convenient to be able to specify the exact bits of a
floating-point literal. For example, you may want to set a
floating-point register to a denormalized value, or to a particular
NaN.
In C, you can do this by combining the "{}" cast with an array
literal, like:
(gdb) p {double}{0x576488BDD2AE9FFE}
$1 = 9.8765449999999996e+112
This patch adds a somewhat similar idea to Ada. It extends the lexer
to allow "l" and "f" suffixes in a based literal. The "f" indicates a
floating-point literal, and the "l"s control the size of the
floating-point type.
Note that this differs from Ada's based real literals. I believe
those can also be used to control the bits of a floating-point value,
but they are a bit more cumbersome to use (simplest is binary but
that's also very lengthy). Also, these aren't implemented in GDB.
I chose not to allow this extension to work with based integer
literals with exponents. That didn't seem very useful.
While working on another patch, I noticed that Ada integer literals
with exponents did not work. For example, with one form you get an
error:
(gdb) print 8e2
Invalid digit `e' in based literal
And with another form you get an incorrect value:
(gdb) print 16#8#e2
$2 = 8
This patch fixes the bugs and adds tests.
PR ada/28115 points out that gdb.ada/arrayptr.exp works with GNAT 12,
but fails with minimal encodings in earlier versions.
This patch updates the test to try to report the results correctly. I
tried this with the Fedora 34 system gcc (GCC 11) and with a GCC 12
built from git trunk sometime relatively recently.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28115
Ada allows non-ASCII identifiers, and GNAT supports several such
encodings. This patch adds the corresponding support to gdb.
GNAT encodes non-ASCII characters using special symbol names.
For character sets like Latin-1, where all characters are a single
byte, it uses a "U" followed by the hex for the character. So, for
example, thorn would be encoded as "Ufe" (0xFE being lower case
thorn).
For wider characters, despite what the manual says (it claims
Shift-JIS and EUC can be used), in practice recent versions only
support Unicode. Here, characters in the base plane are represented
using "Wxxxx" and characters outside the base plane using
"WWxxxxxxxx".
GNAT has some further quirks here. Ada is case-insensitive, and GNAT
emits symbols that have been case-folded. For characters in ASCII,
and for all characters in non-Unicode character sets, lower case is
used. For Unicode, however, characters that fit in a single byte are
converted to lower case, but all others are converted to upper case.
Furthermore, there is a bug in GNAT where two symbols that differ only
in the case of "Y WITH DIAERESIS" (and potentially others, I did not
check exhaustively) can be used in one program. I chose to omit
handling this case from gdb, on the theory that it is hard to figure
out the logic, and anyway if the bug is ever fixed, we'll regret
having a heuristic.
This patch introduces a new "ada source-charset" setting. It defaults
to Latin-1, as that is GNAT's default. This setting controls how "U"
characters are decoded -- W/WW are always handled as UTF-32.
The ada_tag_name_from_tsd change is needed because this function will
read memory from the inferior and interpret it -- and this caused an
encoding failure on PPC when running a test that tries to read
uninitialized memory.
This patch implements its own UTF-32-based case folder. This avoids
host platform quirks, and is relatively simple. A short Python
program to generate the case-folding table is included. It simply
relies on whatever version of Unicode is used by the host Python,
which seems basically acceptable.
Test cases for UTF-8, Latin-1, and Latin-3 are included. This
exercises most of the new code paths, aside from Y WITH DIAERESIS as
noted above.
rust-parse.c has a #define for the host-specific UTF-32 charset name.
A later patch needs the same thing, so this patch moves the definition
to charset.h for easier reuse.
Currently, neither phex nor phex_nz handle sizeof_l==1 -- they let
this case fall through to the default case. However, a subsequent
patch in this series needs this case to work correctly.
I looked at all calls to these functions that pass a 1 for the
sizeof_l parameter. The only such case seems to be correct with this
change.
Currently, ada_decode pre-sizes the output string, filling it with 'X'
characters. However, it's a bit simpler and more flexible to let
std::string do the work here, and simply append characters to the
string as we go. This turns out to be useful for a subsequent patch.
Correct issues with INSN2_ALIAS annotation for branch instructions:
- regular MIPS BEQZ/L and BNEZ/L assembly instructions are idioms for
BEQ/L and BNE/L respectively with the `rs' operand equal to $0,
- microMIPS 32-bit BEQZ and BNEZ assembly instructions are idioms for
BEQ and BNE respectively with the `rt' operand equal to $0,
- regular MIPS BAL assembly instruction is an idiom for architecture
levels of up to the MIPSr5 ISA and a machine instruction on its own
from the MIPSr6 ISA up.
Add missing annotation to BEQZ/L and BNEZ/L accordingly then and add a
new entry for BAL for the MIPSr6 ISA, correcting a disassembly bug:
$ mips-linux-gnu-objdump -m mips:isa64r6 -M no-aliases -d bal.o
bal.o: file format elf32-tradlittlemips
Disassembly of section .text:
00000000 <foo>:
0: 04110000 0x4110000
...
$
Add test cases accordingly.
Parts for regular MIPS BEQZ/L and BNEZ/L instructions from Sagar Patel.
2022-03-06 Maciej W. Rozycki <macro@orcam.me.uk>
binutils/
* testsuite/binutils-all/mips/mips1-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips1-branch-noalias.d: New test.
* testsuite/binutils-all/mips/mips2-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips2-branch-noalias.d: New test.
* testsuite/binutils-all/mips/mips32r6-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips32r6-branch-noalias.d: New
test.
* testsuite/binutils-all/mips/micromips-branch-alias.d: New
test.
* testsuite/binutils-all/mips/micromips-branch-noalias.d: New
test.
* testsuite/binutils-all/mips/mips-branch-alias.s: New test
source.
* testsuite/binutils-all/mips/micromips-branch-alias.s: New test
source.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.
2022-03-06 Sagar Patel <sagarmp@cs.unc.edu>
Maciej W. Rozycki <macro@orcam.me.uk>
opcodes/
* mips-opc.c (mips_builtin_opcodes): Fix INSN2_ALIAS annotation
for "bal", "beqz", "beqzl", "bnez" and "bnezl" instructions.
* micromips-opc.c (micromips_opcodes): Likewise for "beqz" and
"bnez" instructions.
This changes iterate_over_block_local_vars and
iterate_over_block_arg_vars to take a gdb::function_view rather than a
function pointer and a user-data. In one spot, this allows us to
remove a helper structure and helper function. In another spot, this
looked more complicated, so I changed the helper function to be an
"operator()" -- also a simplification, just not as big.
I happened to notice a couple of unnecessary casts in hppa-tdep.c, and
then I saw that the use of objfile_key could be simplified -- removing
some code and using the default deleter rather than noop_deleter.
Tested by rebuilding. Let me know what you think.
In a following patch, I have a const value I want to copy using a
value_copy. However, value_copy takes a non-const source value, at the
moment. Change the paramter to be const,
If the source value is not lazy, we currently call
value_contents_all_raw, which calls allocate_value_contents, to get a
view on the contents. They both take a non-const value, that's a
problem. My first attempt at solving it was to add a const version of
value_contents_all_raw, make allocate_value_contents take a const value,
and either:
- make value::contents mutable
- make allocate_value_contents cast away the const
The idea being that allocating the value contents buffer does modify the
value at the bit level, but logically that doesn't change its state.
That was getting a bit complicated, so what I ended up doing is make
value_copy not call value_contents_all_raw. We know at this point that
the value is not lazy, so value::contents must have been allocate
already.
Change-Id: I3741ab362bce14315f712ec24064ccc17e3578d4
No kind of internal var uses it remove it. This makes the transition to
using a variant easier, since we don't need to think about where this
should be called (in a destructor or not), if it can throw, etc.
Change-Id: Iebbc867d1ce6716480450d9790410d6684cbe4dd
The vDSO objfile is not a real file, so mark it as such. I noticed
this because, when playing with debuginfod, I saw:
Downloading 0.01 MB separate debug info for /tmp/system-supplied DSO at 0x7ffff7fc9000
That "/tmp" is wrong -- it's just gdb's cwd. This patch corrects the
problem, resulting in:
Downloading 0.01 MB separate debug info for system-supplied DSO at 0x7ffff7fc9000
Regression tested on x86-64 Fedora 34.
Clangd shows a warning about misleading indentation in this file, fix
it.
binutils/ChangeLog:
* readelf.c (process_dynamic_section): Fix indentation.
Change-Id: I43a7f4f4c75dd080af614222b980526f5debf297
GDB prints the wrong type for typedefs in case there is another typedef
available for the same raw type (gdb/16040). The reason is that the
current hashmap based substitution mechanism always compares the target
type of a typedef and not its scoped name.
The original output of GDB for a program like
~~~~
namespace ns
{
typedef double scoped_double;
}
typedef double global_double;
class TypedefHolder
{
public:
double a;
ns::scoped_double b;
global_double c;
private:
typedef double class_double;
class_double d;
double method1(ns::scoped_double) { return 24.0; }
double method2(global_double) { return 24.0; }
};
int main()
{
TypedefHolder th;
return 0;
}
~~~~
is
~~~~
(gdb) b 27
Breakpoint 1 at 0x1131: file TypedefHolder.cc, line 27.
(gdb) r
Starting program: /tmp/typedefholder
Breakpoint 1, main () at TypedefHolder.cc:27
27 return 0;
(gdb) ptype th
type = class TypedefHolder {
public:
class_double a;
class_double b;
class_double c;
private:
class_double d;
class_double method1(class_double);
class_double method2(class_double);
typedef double class_double;
}
~~~~
Basically all attributes of a class which have the raw type "double" are
substituted by "class_double".
With the patch the output is the following
~~~~
type = class TypedefHolder {
public:
double a;
ns::scoped_double b;
global_double c;
private:
class_double d;
double method1(ns::scoped_double);
double method2(global_double);
typedef double class_double;
}
~~~~
Presently in this case, due to an undefined behavior shift, at least
with x86 cross builds I'm observing:
Error: value conflicts with instruction length `8,0x0000003f'
Eliminate the UB and extend the respective testcase.
On some systems, the gnulib configuration will decide to define open
and/or close as macros to replace the POSIX C functions. This
interferes with using those names in C++ class or namespace scopes.
gdbsupport/
* event-pipe.cc (event_pipe::open): Renamed to ...
(event_pipe::open_pipe): ... this.
(event_pipe::close): Renamed to ...
(event_pipe::close_pipe): ... this.
* event-pipe.h (class event_pipe): Updated.
gdb/
* inf-ptrace.h (async_file_open, async_file_close): Updated.
gdbserver/
* gdbserver/linux-low.cc (linux_process_target::async): Likewise.
When execute the following command:
make check-gdb TESTS="gdb.base/gdb-caching-proc.exp"
we can see there exist some failed testcases:
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 1: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 2: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 3: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 4: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 5: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 6: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 7: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 8: can spawn for attach (got interactive prompt)
FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 9: can spawn for attach (got interactive prompt)
here are the detailed messages in gdb/testsuite/gdb.log:
attach 873776
A program is being debugged already. Kill it? (y or n) n
Not killed.
(gdb) FAIL: gdb.base/gdb-caching-proc.exp: can_spawn_for_attach: 0: can spawn for attach (got interactive prompt)
so handle the case "A program is being debugged already. Kill it" in
can_spawn_for_attach to fix the failed testcases.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Section addresses can change between ppc64_elf_size_stubs and
ppc64_elf_build_stubs due to .eh_frame editing. The idea of stashing
r_offset final addresses calculated in ppc64_elf_size_stubs for use by
ppc64_elf_build_stubs was never a good idea. Instead, we need to keep
section/offset pairs.
* elf64-ppc.c (struct ppc_link_hash_table): Delete relr_addr.
Add relr section/offset array.
(append_relr_off): Rewrite. Update all callers.
(sort_relr): New function.
(ppc64_elf_size_stubs): Adjust to suit new relative reloc stash.
(ppc64_elf_build_stubs): Likewise.
