Existing ports already have sizeof_pc set to the same size as sim_cia,
so simply make that part of the core code. We already assume this in
places by way of sim_pc_{get,set}, and this is how it's documented in
the sim-base.h API.
There is code to allow sims to pick different register word sizes from
address sizes, but most ports use the defaults for both (32-bits), and
the few that support multiple register sizes never change the address
size (so address defaults to register). I can't think of any machine
where the register hardware size would be larger than the address word
size either. We have ABIs that behave that way (e.g. x32), but the
hardware is still equivalent register sized.
When the target's PC is 64-bits, this shift expands into a range of
8 * 8 - 1 which doesn't work with 32-bit constants. Force it to be
a 64-bit value all the time and let the compiler truncate it.
This port doesn't build if these hardware modules are omitted, and
there's no reason we need to make it conditional at build time, so
always enable it. The hardware devices only get turned on if the
user requests it at runtime via hardware settings.
Consider the test-case small.c:
...
$ cat -n small.c
1 __attribute__ ((noinline, noclone))
2 int foo (char *c)
3 {
4 asm volatile ("" : : "r" (c) : "memory");
5 return 1;
6 }
7
8 int main ()
9 {
10 char tpl1[20] = "/tmp/test.XXX";
11 char tpl2[20] = "/tmp/test.XXX";
12 int fd1 = foo (tpl1);
13 int fd2 = foo (tpl2);
14 if (fd1 == -1) {
15 return 1;
16 }
17
18 return 0;
19 }
...
Compiled with gcc-8 and optimization:
...
$ gcc-8 -O2 -g small.c
...
We step through the calls to foo, but fail to visit line 13:
...
12 int fd1 = foo (tpl1);
(gdb) step
foo (c=c@entry=0x7fffffffdea0 "/tmp/test.XXX") at small.c:5
5 return 1;
(gdb) step
foo (c=c@entry=0x7fffffffdec0 "/tmp/test.XXX") at small.c:5
5 return 1;
(gdb) step
main () at small.c:14
14 if (fd1 == -1) {
(gdb)
...
This is caused by the following. The calls to foo are implemented by these
insns:
....
4003df: 0f 29 04 24 movaps %xmm0,(%rsp)
4003e3: 0f 29 44 24 20 movaps %xmm0,0x20(%rsp)
4003e8: e8 03 01 00 00 callq 4004f0 <foo>
4003ed: 48 8d 7c 24 20 lea 0x20(%rsp),%rdi
4003f2: 89 c2 mov %eax,%edx
4003f4: e8 f7 00 00 00 callq 4004f0 <foo>
4003f9: 31 c0 xor %eax,%eax
...
with corresponding line table entries:
...
INDEX LINE ADDRESS IS-STMT
8 12 0x00000000004003df Y
9 10 0x00000000004003df
10 11 0x00000000004003e3
11 12 0x00000000004003e8
12 13 0x00000000004003ed
13 12 0x00000000004003f2
14 13 0x00000000004003f4 Y
15 13 0x00000000004003f4
16 14 0x00000000004003f9 Y
17 14 0x00000000004003f9
...
Once we step out of the call to foo at 4003e8, we land at 4003ed, and gdb
enters process_event_stop_test to figure out what to do.
That entry has is-stmt=n, so it's not the start of a line, so we don't stop
there. However, we do update ecs->event_thread->current_line to line 13,
because the frame has changed (because we stepped out of the function).
Next we land at 4003f2. Again the entry has is-stmt=n, so it's not the start
of a line, so we don't stop there. However, because the frame hasn't changed,
we don't update update ecs->event_thread->current_line, so it stays 13.
Next we land at 4003f4. Now is-stmt=y, so it's the start of a line, and we'd
like to stop here.
But we don't stop because this test fails:
...
if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc)
&& (ecs->event_thread->current_line != stop_pc_sal.line
|| ecs->event_thread->current_symtab != stop_pc_sal.symtab))
{
...
because ecs->event_thread->current_line == 13 and stop_pc_sal.line == 13.
Fix this by resetting ecs->event_thread->current_line to 0 if is-stmt=n and
the frame has changed, such that we have:
...
12 int fd1 = foo (tpl1);
(gdb) step
foo (c=c@entry=0x7fffffffdbc0 "/tmp/test.XXX") at small.c:5
5 return 1;
(gdb) step
main () at small.c:13
13 int fd2 = foo (tpl2);
(gdb)
...
Tested on x86_64-linux, with gcc-7 and gcc-8.
gdb/ChangeLog:
2021-01-29 Tom de Vries <tdevries@suse.de>
PR breakpoints/26063
* infrun.c (process_event_stop_test): Reset
ecs->event_thread->current_line to 0 if is-stmt=n and frame has
changed.
gdb/testsuite/ChangeLog:
2021-01-29 Tom de Vries <tdevries@suse.de>
PR breakpoints/26063
* gdb.dwarf2/dw2-step-out-of-function-no-stmt.c: New test.
* gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp: New file.
When running test-case gdb.opt/solib-intra-step.exp with target board
unix/-m32 and gcc-10, I run into:
...
(gdb) step^M
__x86.get_pc_thunk.bx () at ../sysdeps/i386/crti.S:68^M
68 ../sysdeps/i386/crti.S: No such file or directory.^M
(gdb) step^M
shlib_second (dummy=0) at solib-intra-step-lib.c:23^M
23 abort (); /* second-hit */^M
(gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit
...
The problem is that the test-case expects to step past the retry line,
which is optional.
Fix this by removing the state tracking logic from the gdb_test_multiples. It
makes the test more difficult to understand, and doesn't specifically test for
faulty gdb behaviour.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-29 Tom de Vries <tdevries@suse.de>
* gdb.opt/solib-intra-step.exp: Remove state tracking logic.
bfd/
PR 27271
* elflink.c (bfd_elf_link_record_dynamic_symbol): Don't segfault
on symbols defined in absolute or other special sections.
ld/
* testsuite/ld-tic6x/tic6x.exp: Add pr27271 test.
I spotted that every time thr_try_catch_cmd is called GDB has already
switched to the required thread. The call to switch_to_thread at the
head of thr_try_catch_cmd is therefore redundant.
This commit replaces the call to switch_to_thread with an assertion
that we already have the required thread selected.
I also extended the header comment on thr_try_catch_cmd to make it
clearer when this function could throw an exception.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* thread.c (thr_try_catch_cmd): Replace swith_to_thread with an
assert. Extend the header comment.
The locator window, or status window as it is sometimes called is
handled differently to all the other windows.
The reason for this is that the class representing this
window (tui_locator_window) does two jobs, first this class represents
a window just like any other that has space on the screen and fills
the space with content. The second job is that this class serves as a
storage area to hold information about the current location that the
TUI windows represent, so the class has members like 'addr' and
'line_no', for example which are used within this class, and others
when they want to know which line/address the TUI windows should be
showing to the user.
Because of this dual purpose we must always have an instance of the
tui_locator_window so that there is somewhere to store this location
information.
The result of this is that the locator window must never be deleted
like other windows, which results in some special case code.
In this patch I propose splitting the two roles of the
tui_locator_window class. The tui_locator_window class will retain
just its window drawing parts, and will be treated just like any other
window. This should allow all special case code for this window to be
deleted.
The other role, that of tracking the current tui location will be
moved into a new class (tui_location_tracker), of which there will be
a single global instance. All of the places where we previously use
the locator window to get location information will now be updated to
get this from the tui_location_tracker.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* Makefile.in (SUBDIR_TUI_SRCS): Add tui/tui-location.c.
(HFILES_NO_SRCDIR): Add tui/tui-location.h.
* tui/tui-data.h (TUI_STATUS_WIN): Define.
(tui_locator_win_info_ptr): Delete declaration.
* tui/tui-disasm.c: Add 'tui/tui-location.h' include.
(tui_disasm_window::set_contents): Fetch state from tui_location
global.
(tui_get_begin_asm_address): Likewise.
* tui/tui-layout.c (tui_apply_current_layout): Remove special case
for locator window.
(get_locator_window): Delete.
(initialize_known_windows): Treat locator window just like all the
rest.
* tui/tui-source.c: Add 'tui/tui-location.h' include.
(tui_source_window::set_contents): Fetch state from tui_location
global.
(tui_source_window::showing_source_p): Likewise.
* tui/tui-stack.c: Add 'tui/tui-location.h' include.
(_locator): Delete.
(tui_locator_win_info_ptr): Delete.
(tui_locator_window::make_status_line): Fetch state from
tui_location global.
(tui_locator_window::rerender): Remove check of 'handle',
reindent function body.
(tui_locator_window::set_locator_fullname): Delete.
(tui_locator_window::set_locator_info): Delete.
(tui_update_locator_fullname): Delete.
(tui_show_frame_info): Likewise.
(tui_show_locator_content): Access window through TUI_STATUS_WIN.
* tui/tui-stack.h (tui_locator_window::set_locator_info): Moved to
tui/tui-location.h and renamed to
tui_location_tracker::set_location.
(tui_locator_window::set_locator_fullname): Moved to
tui/tui-location.h and renamed to
tui_location_tracker::set_fullname.
(tui_locator_window::full_name): Delete.
(tui_locator_window::proc_name): Delete.
(tui_locator_window::line_no): Delete.
(tui_locator_window::addr): Delete.
(tui_locator_window::gdbarch): Delete.
(tui_update_locator_fullname): Delete declaration.
* tui/tui-wingeneral.c (tui_refresh_all): Removed special handling
for locator window.
* tui/tui-winsource.c: Add 'tui/tui-location.h' include.
(tui_display_main): Call function on tui_location directly.
* tui/tui.h (enum tui_win_type): Add STATUS_WIN.
* tui/tui-location.c: New file.
* tui/tui-location.h: New file.
When running test-case gdb.arch/i386-gnu-cfi.exp with target board unix/-m32, I get:
...
(gdb) up 3^M
79 abort.c: No such file or directory.^M
(gdb) FAIL: gdb.arch/i386-gnu-cfi.exp: shift up to the modified frame
...
The preceding backtrace looks like this:
...
(gdb) bt^M
#0 0xf7fcf549 in __kernel_vsyscall ()^M
#1 0xf7ce8896 in __libc_signal_restore_set (set=0xffffc3bc) at \
../sysdeps/unix/sysv/linux/internal-signals.h:104^M
#2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:47^M
#3 0xf7cd0314 in __GI_abort () at abort.c:79^M
#4 0x0804919f in gate (gate=0x8049040 <abort@plt>, data=0x0) at gate.c:3^M
#5 0x08049176 in main () at i386-gnu-cfi.c:27^M
...
with function gate at position #4, while on another system where the test passes,
I see instead function gate at position #3.
Fix this by capturing the position of function gate in the backtrace, and
using that in the rest of the test instead of hardcoded constant 3.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-28 Tom de Vries <tdevries@suse.de>
* gdb.arch/i386-gnu-cfi.exp: Capture the position of function gate
in the backtrace, and use that in the rest of the test instead of
hardcoded constant 3. Use "frame" instead of "up" for robustness.
When running test-case gdb.arch/i386-sse-stack-align.exp on target board
unix/-m32, I run into:
...
(gdb) print (int) g0 ()^M
Invalid data type for function to be called.^M
(gdb) FAIL: gdb.arch/i386-sse-stack-align.exp: print (int) g0 ()
...
Gdb is supposed to use minimal symbol g0:
...
$ nm i386-sse-stack-align | grep g0
08049194 t g0
...
but instead it finds a g0 symbol in the debug info of libm, specifically in
./sysdeps/ieee754/ldbl-96/e_lgammal_r.c.
Fix this by renaming g[0-4] to test_g[0-4].
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-28 Tom de Vries <tdevries@suse.de>
* gdb.arch/i386-sse-stack-align.S: Rename g[0-4] to test_g[0-4].
* gdb.arch/i386-sse-stack-align.c: Same.
* gdb.arch/i386-sse-stack-align.exp: Same.
I think this makes the names of the methods clearer, especially for the
arch. The type::arch method (which gets the arch owner, or NULL if the
type is not arch owned) is easily confused with the get_type_arch method
(which returns an arch no matter what). The name "arch_owner" will make
it intuitive that the method returns NULL if the type is not arch-owned.
Also, this frees the type::arch name, so we will be able to morph the
get_type_arch function into the type::arch method.
gdb/ChangeLog:
* gdbtypes.h (struct type) <arch>: Rename to...
<arch_owner>: ... this, update all users.
<objfile>: Rename to...
<objfile_owner>: ... this, update all users.
Change-Id: Ie7c28684c7b565adec05a7619c418c69429bd8c0
The .debug_line secton in DWARF5 has a byte for address size and a byte
for segment selector after DWARF version. Skip them for DWARF5.
PR gold/27246
* dwarf_reader.cc (Sized_dwarf_line_info::read_header_prolog):
Skip address size and segment selector for DWARF5.
Since this commit:
commit 64aaad6349
Date: Fri Sep 25 14:50:56 2020 +0100
gdb: use get_standard_config_dir when looking for .gdbinit
GDB has been checking for ${XDG_CONFIG_HOME}/gdb/gdbinit on startup.
Most tests pass -nx to GDB to block loading of gdbinit files, but
there are a few tests (e.g. gdb.base/gdbinit-history.exp) that don't
use -nx and instead setup a fake HOME directory containing a gdbinit
file.
However, since the above commit, if XDG_CONFIG_HOME is set then once
-nx is no longer being passed GDB will load any gdbinit file it finds
in that directory, which could cause the test to fail.
As a concrete example:
$ mkdir -p fake_xdg_config_home/gdb/
$ cat <<EOF >fake_xdg_config_home/gdb/gdbinit
echo goodbye\n
quit
EOF
$ export XDG_CONFIG_HOME=$PWD/fake_xdg_config_home
$ make check-gdb TESTS="gdb.base/gdbinit-history.exp"
Should result in the test failing.
The solution I propose is to unset XDG_CONFIG_HOME in
default_gdb_init, we already unset a bunch of environment variables in
this proc.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (default_gdb_init): Unset XDG_CONFIG_HOME.
The function execute_command_to_string had two header comments, one in
gdbcmd.h and one in top.c.
This commit merges the two comments into one and places this comment
in gdbcmd.h. The comment in top.c is updated to just reference
gdbcmd.h.
gdb/ChangeLog:
* gdbcmd.h (execute_command_to_string): Update comment.
* top.c (execute_command_to_string): Update header comment.
When running test-case gdb.base/longjmp.exp with target board unix/-m32, we
run into:
...
(gdb) next^M
Warning:^M
Cannot insert breakpoint 0.^M
Cannot access memory at address 0x7dbf7353^M
^M
__libc_siglongjmp (env=0x804a040 <env>, val=1) at longjmp.c:28^M
28 longjmps++;^M
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
...
The failure to access memory happens in i386_get_longjmp_target and is due to
glibc having pointer encryption (aka "pointer mangling" or "pointer guard") of
the long jump buffer. This is a known problem.
In create_longjmp_master_breakpoint (which attempts to install a master
longjmp breakpoint) a preference scheme is present, which installs a
probe breakpoint if a libc:longjmp probe is present, and otherwise falls back
to setting breakpoints at the names in the longjmp_names array.
But in fact, both the probe breakpoint and the longjmp_names breakpoints are
set. The latter ones are set when processing libc.so.debug, and the former
one when processing libc.so. In other words, this is the longjmp variant of
PR26881, which describes the same problem for master exception breakpoints.
This problem only triggers when the glibc debug info package is installed,
which is not due to the debug info itself in libc.so.debug, but due to the
minimal symbols (because create_longjmp_master_breakpoint uses minimal symbols
to translate the longjmp_names to addresses).
The problem doesn't trigger for -m64, because there tdep->jb_pc_offset is not
set.
Fix this similar to commit 1940319c0e (the fix for PR26881): only install
longjmp_names breakpoints in libc.so/libc.so.debug if installing the
libc:longjmp probe in libc.so failed.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-01-28 Tom de Vries <tdevries@suse.de>
PR breakpoints/27205
* breakpoint.c (create_longjmp_master_breakpoint_probe)
(create_longjmp_master_breakpoint_names): New function, factored out
of ...
(create_longjmp_master_breakpoint): ... here. Only try to install
longjmp_names breakpoints in libc.so/libc.so.debug if installing probe
breakpoint in libc.so failed.
This stops ld from endless looping on SHF_LINK_ORDER sh_link loops.
bfd/
PR 27259
* elflink.c (_bfd_elf_gc_mark_extra_sections): Use linker_mark to
prevent endless looping of linked-to sections.
ld/
PR 27259
* ldelf.c (ldelf_before_place_orphans): Use linker_mark to
prevent endless looping of linked-to sections.
When running test-case gdb.ada/out_of_line_in_inlined.exp with target board
unix/-m32 on a system with gcc-10 default compiler, we run into:
...
(gdb) break foo_o224_021.child1.child2^M
Breakpoint 1 at 0x804ba59: foo_o224_021.child1.child2. (3 locations)^M
(gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
break foo_o224_021.child1.child2
...
The test does not expect the "3 locations" part.
Fix this by using gdb_breakpoint instead of gdb_test.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-28 Tom de Vries <tdevries@suse.de>
* gdb.ada/out_of_line_in_inlined.exp: Use gdb_breakpoint.
When running test-case gdb.dwarf2/dw2-out-of-range-end-of-seq.exp on a
system with debug packages installed, I run into:
...
(gdb) maint info line-table^M
... <lots of output> ...
ERROR: internal buffer is full.
UNRESOLVED: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: \
END with address 1 eliminated
...
Fix this by limiting the output of the command using a regexp.
I also noticed that when making the regexp match nothing, meaning
the command has no output, the test didn't FAIL. Fixed this by adding a
PASS pattern.
I also noticed that the FAIL pattern didn't work with -m32, fixed that as
well.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-28 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: Add regexp to
"maint info line-table". Make PASS pattern more specific. Make
FAIL pattern work for -m32.
This patch addresses PR gdb/27133. Before it, the following succession
of commands would cause gdb to crash:
set logging redirect on
set logging debugredirect on
set logging on
The problem eventually comes down to a use after free. The function
cli_interp_base::set_logging is called with a unique_ptr argument that
holds a pointer to the redirection file. In the problematic use case,
no-one ever took ownership of that pointer (as far as unique_ptr is
concerned), so the call to its dtor at the end of the function causes
the file object to be deleted. Any later use of the pointer to the
redirection file is therefore an error.
This patch ensures that the unique_ptr is released when required (so it
does not assume ownership anymore). The internal logic of
cli_interp_base::set_logging takes care of freeing the ui_file when it
is not necessary anymore using the saved_output.file_to_delete field.
gdb/ChangeLog:
PR gdb/27133
* cli/cli-interp.c (cli_interp_base::set_logging): Ensure the
unique_ptr is released when the wrapped pointer is kept for later
use.
gdb/testsuite/ChangeLog:
PR gdb/27133
* gdb.base/ui-redirect.exp: Add test case that ensures that
redirecting both logging and debug does not cause gdb to crash.
Enable displaced stepping over a BR/BLR instruction
Displaced stepping over an instruction executes a instruction in a
scratch area and then manually fixes up the PC address to leave
execution where it would have been if the instruction were in its
original location.
The BR instruction does not need modification in order to run correctly
at a different address, but the displaced step fixup method should not
manually adjust the PC since the BR instruction sets that value already.
The BLR instruction should also avoid such a fixup, but must also have
the link register modified to point to just after the original code
location rather than back to the scratch location.
This patch adds the above functionality.
We add this functionality by modifying aarch64_displaced_step_others
rather than by adding a new visitor method to aarch64_insn_visitor.
We choose this since it seems that visitor approach is designed
specifically for PC relative instructions (which must always be modified
when executed in a different location).
It seems that the BR and BLR instructions are more like the RET
instruction which is already handled specially in
aarch64_displaced_step_others.
This also means the gdbserver code to relocate an instruction when
creating a fast tracepoint does not need to be modified, since nothing
special is needed for the BR and BLR instructions there.
Regression tests showed nothing untoward on native aarch64 (though it
took a while for me to get the testcase to account for PIE).
------#####
Original observed (mis)behaviour before was that displaced stepping over
a BR or BLR instruction would not execute the function they called.
Most easily seen by putting a breakpoint with a condition on such an
instruction and a print statement in the functions they called.
When run with the breakpoint enabled the function is not called and
"numargs called" is not printed.
When run with the breakpoint disabled the function is called and the
message is printed.
--- GDB Session
~ [15:57:14] % gdb ../using-blr
Reading symbols from ../using-blr...done.
(gdb) disassemble blr_call_value
Dump of assembler code for function blr_call_value:
...
0x0000000000400560 <+28>: blr x2
...
0x00000000004005b8 <+116>: ret
End of assembler dump.
(gdb) break *0x0000000000400560
Breakpoint 1 at 0x400560: file ../using-blr.c, line 22.
(gdb) condition 1 10 == 0
(gdb) run
Starting program: /home/matmal01/using-blr
[Inferior 1 (process 33279) exited with code 012]
(gdb) disable 1
(gdb) run
Starting program: /home/matmal01/using-blr
numargs called
[Inferior 1 (process 33289) exited with code 012]
(gdb)
Test program:
---- using-blr ----
\#include <stdio.h>
typedef int (foo) (int, int);
typedef void (bar) (int, int);
struct sls_testclass {
foo *x;
bar *y;
int left;
int right;
};
__attribute__ ((noinline))
int blr_call_value (struct sls_testclass x)
{
int retval = x.x(x.left, x.right);
if (retval % 10)
return 100;
return 9;
}
__attribute__ ((noinline))
int blr_call (struct sls_testclass x)
{
x.y(x.left, x.right);
if (x.left % 10)
return 100;
return 9;
}
int
numargs (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
printf("numargs called\n");
return 10;
}
void
altfunc (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
printf("altfunc called\n");
}
int main(int argc, char **argv)
{
struct sls_testclass x = { .x = numargs, .y = altfunc, .left = 1, .right = 2 };
if (argc > 2)
{
blr_call (x);
}
else
blr_call_value (x);
return 10;
}
Internally at AdaCore, documentation is still built with Texinfo 4.13.
This version gave an error when building gdb.texinfo:
../../../binutils-gdb/gdb/doc/gdb.texinfo:27672: @pxref expected braces.
../../../binutils-gdb/gdb/doc/gdb.texinfo:27672: ` {dotdebug_gdb_scripts section,,The @cod...' is too long for expansion; not expanded.
... followed by many more spurious errors that were caused by this
one.
This patch fix the problem by removing the extra space.
I don't know whether it's advisable to try to support this ancient
version of Texinfo (released in 2008 apparently); but in this
particular case the fix is trivial, so I'm checking it in.
gdb/doc/ChangeLog
2021-01-27 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Auto-loading extensions): Remove extraneous space.
Since ld may depend on libctf (if present), and libctf may be relinked
by the installation process, libctf must be installed before ld is,
or the relink may fail if it calls on symbols or symbol versions that do
not exist in any libctf already present on the system. (If none is
present, the copy in the build tree will be automatically used, but
if one *is* present, it may take precedence and break things.)
(This is a maybe- dependency, so it will work even if libctf is
disabled.)
ChangeLog
2021-01-26 Nick Alcock <nick.alcock@oracle.com>
PR 27250
* Makefile.def: Add install-libctf dependency to install-ld.
* Makefile.in: Regenerated.
GCC 11 passes --gdwarf-5 to assembler to enable DWARF5 debug info. Don't
disable relaxation when --gdwarf-N is specified. The assembler generated
debug information will treat the sequence of the relaxed instructions as
a single instruction.
PR gas/27243
* config/tc-nios2.c (md_begin): Don't disable relaxation with
--gdwarf-N.
* testsuite/gas/nios2/relax.d: New file.
* testsuite/gas/nios2/relax.s: Likewise.
This changes windows-nat.c and nat/windows-nat.c to use the new
debug_prefixed_printf_cond facility. I tried this out on a Windows
build and I think it makes the output look a little nicer.
2021-01-26 Tom Tromey <tromey@adacore.com>
* windows-nat.c (DEBUG_EXEC, DEBUG_EVENTS, DEBUG_MEM)
(DEBUG_EXCEPT): Use debug_prefixed_printf_cond.
(windows_init_thread_list, windows_nat::handle_load_dll)
(windows_nat::handle_unload_dll, windows_nat_target::resume)
(windows_nat_target::resume)
(windows_nat_target::get_windows_debug_event)
(windows_nat_target::interrupt, windows_xfer_memory)
(windows_nat_target::close): Update.
* nat/windows-nat.c (DEBUG_EVENTS): Use
debug_prefixed_printf_cond.
(matching_pending_stop, fetch_pending_stop)
(continue_last_debug_event): Update.
Adds a trivial wrapper over elfcore_write_note, primarily to be more
consistent with other ELF note helper functions and highlight NT_FILE as
one of notes handled by gdb.
bfd/ChangeLog:
2020-12-17 Mihails Strasuns <mihails.strasuns@intel.com>
* bfd-elf.h (elfcore_write_file_note): New function.
* elf.c (elfcore_write_file_note): New function.
gdb/ChangeLog:
2020-12-17 Mihails Strasuns <mihails.strasuns@intel.com>
* linux-tdep.c (linux_make_mappings_corefile_notes): Start using
elfcore_write_file_note.
This makes it possible to build ld without any compiled-in scripts,
by setting COMPILE_IN=no in the environment. pe, beos and pdp11
targets didn't support scripts from the file system, with pdp11
nastily editing the ld/ldscripts file so that the built-in script
didn't match.
PR 27226
* emulparams/alphavms.sh: Don't set COMPILE_IN.
* emulparams/elf64_ia64_vms.sh: Likewise.
* emulparams/elf64mmix.sh: Likewise.
* emulparams/elf_iamcu.sh: Likewise.
* emulparams/elf_k1om.sh: Likewise.
* emulparams/elf_l1om.sh: Likewise.
* emulparams/mmo.sh: Likewise.
* emulparams/pdp11.sh: Set DATA_SEG_ADDR.
* scripttempl/pdp11.sc: Use it.
* emultempl/pdp11.em: Don't edit .xn script for separate_code,
instead use .xe script. Support scripts from file system.
* emultempl/beos.em: Support scripts from file system.
* emultempl/pe.em: Likewise.
* emultempl/pep.em: Likewise.
* testsuite/ld-bootstrap/bootstrap.exp: Make tmpdir/ldscripts link.
This replaces skip and notarget in a number of gas tests with xfail,
the idea being that running tests might expose segmentation faults or
other serious errors even when we don't expect a test to pass. Doing
so showed a number of cases where tests now pass, which is another
reason to avoid profligate use of notarget and skip.
* testsuite/gas/all/local-label-overflow.d: Use xfail rather than
notarget all except hppa. Comment.
* testsuite/gas/all/sleb128-2.d: Use xfail rather than notarget.
* testsuite/gas/all/sleb128-4.d: Likewise. Don't skip msp430.
* testsuite/gas/all/sleb128-5.d: Use xfail rather than notarget.
* testsuite/gas/all/sleb128-7.d: Likewise.
* testsuite/gas/all/sleb128-9.d: Likewise.
* testsuite/gas/elf/bignums.d: Likewise.
* testsuite/gas/elf/group0c.d: Likewise.
* testsuite/gas/elf/group1a.d: Likewise.
* testsuite/gas/elf/section-symbol-redef.d: Likewise.
* testsuite/gas/elf/section15.d: Likewise.
* testsuite/gas/elf/section4.d: Likewise.
* testsuite/gas/elf/section7.d: Likewise.
* testsuite/gas/macros/irp.d: Likewise.
* testsuite/gas/macros/repeat.d: Likewise.
* testsuite/gas/macros/rept.d: Likewise.
* testsuite/gas/macros/test2.d: Likewise.
* testsuite/gas/macros/vararg.d: Likewise.
* testsuite/gas/all/string.d: Use xfail rather than skip.
* testsuite/gas/elf/missing-build-notes.d: Likewise.
* testsuite/gas/elf/section0.d: Likewise.
* testsuite/gas/elf/section1.d: Likewise.
* testsuite/gas/elf/section10.d: Likewise.
* testsuite/gas/elf/section11.d: Likewise.
* testsuite/gas/elf/section6.d: Likewise.
* testsuite/gas/elf/symtab.d: Use xfail rather than skip, adjust hppa.
* testsuite/gas/elf/symtab.s: Don't start directives in first column.
* testsuite/gas/macros/test3.d: Don't notarget nds32.
skip *-*-* is a little silly, delete the test.
* testsuite/gas/all/byte.d,
* testsuite/gas/all/byte.l,
* testsuite/gas/all/byte.s: Delete.
* testsuite/gas/all/gas.exp: Don't run byte test.
This failed on ft32, hppa, and mips-irix targets. In the case of ft32
the problem was iterating over an array in reverse and not using the
proper condition, so BFD_RELOC_NONE was not recognised.
bfd/
* elf32-ft32.c (ft32_reloc_type_lookup): Don't miss ft32_reloc_map[0].
gas/
PR 27282
* testsuite/gas/all/none.d: Replace skip with xfail, don't xfail ft32.
* testsuite/gas/elf/pr27228.d: xfail hppa and allow OBJECT match.
There is no reggroups set in ARC. If a "maintenance print reggroups"
command is issued, the default register set is dumped (which is fine).
However, if a new group is added via an XML file, then that will
become the _only_ group. This behavior causes gdb.xml/tdesc-regs.exp
to fail.
Fixes gdb.xml/tdesc-regs.exp on ARC.
gdb/ChangeLog:
* arc-tdep.c (arc_add_reggroups): New function.
(arc_gdbarch_init): Call arc_add_reggroups.
When running test-case gdb.threads/killed-outside.exp with target board
unix/-m32, we run into:
...
(gdb) PASS: gdb.threads/killed-outside.exp: get pid of inferior
Executing on target: kill -9 10969 (timeout = 300)
spawn -ignore SIGHUP kill -9 10969^M
continue^M
Continuing.^M
[Thread 0xf7cb4b40 (LWP 10973) exited]^M
^M
Program terminated with signal SIGKILL, Killed.^M
The program no longer exists.^M
(gdb) FAIL: gdb.threads/killed-outside.exp: prompt after first continue
...
Fix this by allowing this output.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-26 Tom de Vries <tdevries@suse.de>
* gdb.threads/killed-outside.exp: Allow regular output.
When running test-case gdb.opt/solib-intra-step.exp with target board
unix/-m32, we run into:
...
(gdb) step^M
__x86.get_pc_thunk.bx () at ../sysdeps/i386/crti.S:66^M
66 ../sysdeps/i386/crti.S: No such file or directory.^M
(gdb) FAIL: gdb.opt/solib-intra-step.exp: first-hit (optimized)
...
The thunk is a helper function for PIC, and given that we have line info for
it, we step into.
Fix this by allowing the step into the thunk, and stepping out of it.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-26 Tom de Vries <tdevries@suse.de>
* gdb.opt/solib-intra-step.exp: Handle stepping into thunk.
