Rename thread_info::executing to thread_info::m_executing, and make it
private. Add a new get/set member functions, and convert GDB to make
use of these.
The only real change of interest in this patch is in thread.c where I
have deleted the helper function set_executing_thread, and now just
use the new set function thread_info::set_executing. However, the old
helper function set_executing_thread included some code to reset the
thread's stop_pc, so I moved this code into the new function
thread_info::set_executing. However, I don't believe there is
anywhere that this results in a change of behaviour, previously the
executing flag was always set true through a call to
set_executing_thread anyway.
The guile API has (history-append! <value>) to add values into GDB's
history list. There is currently no equivalent in the Python API.
This commit adds gdb.add_history(<value>) to the Python API, this
function takes <value> a gdb.Value (or anything that can be passed to
the constructor of gdb.Value), and adds the value it represents to
GDB's history list. The index of the newly added value is returned.
When reverting commit 5a20fadc84 and using gdb_unload instead of runto "bar"
to trigger the internal-error in test-case
gdb.dwarf2/locexpr-data-member-location.exp, we run into:
...
ERROR: couldn't unload file in $gdb (timeout).
...
and the test-case takes about 1 minute.
Fix this by handling internal-error in gdb_unload, such that we have:
...
ERROR: Couldn't unload file in $gdb (GDB internal error).
ERROR: Could not resync from internal error (eof)
...
within 2 seconds.
Tested on x86_64-linux.
When reverting commit 5a20fadc84 the test-case
gdb.dwarf2/locexpr-data-member-location.exp fails like this:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
(GDB internal error)
ERROR: Could not resync from internal error (eof)
...
and takes 1 minute to run.
The long running time is caused by running into a timeout in gdb_run_cmd, at
this point:
...
(gdb) run ^M
The program being debugged has been started already.^M
Start it from the beginning? (y or n) y^M
/home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:5583: internal-error: \
Unexpected type field location kind: 4^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n)
...
Fix this by detecting the internal-error in gdb_run_cmd. We don't handle it
in gdb_run_cmd, but stash the gdb output back into the buffer using
-notransfer, and let the caller proc runto deal with it.
After the fix, the test-case just takes 2 seconds.
Tested on x86_64-linux.
A previous commit added the
gdb.arch/riscv64-unwind-prologue-with-ld-lw.exp testcase, but one of its
associated file was named after a previous version of the test.
This commit fixes this and makes sure that all the files linked to this
testcase share the same prefix in the name.
Tested on riscv64 GNU/Linux.
Before commit 5a20fadc84 the test-case
gdb.dwarf2/locexpr-data-member-location.exp fails like this:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
(GDB internal error)
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n" answer
incr count
}
-re "Create ..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp9 not open
ERROR: Could not resync from internal error (timeout)
...
Fix the:
...
ERROR: : spawn id exp9 not open
...
by handling eof in gdb_internal_error_resync, such that we have instead:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
(GDB internal error)
ERROR: Could not resync from internal error (eof)
...
Tested on x86_64-linux.
The case for FIELD_LOC_KIND_DWARF_BLOCK was missing for
switch TYPE_FIELD_LOC_KIND. Thas caused an internal-error
under some circumstances.
Fixes bug 28030.
On a machine on Open Build Service I'm running into a SIGILL for test-case
gdb.arch/amd64-disp-step-avx.exp:
...
Program received signal SIGILL, Illegal instruction.^M
test_rip_vex2 () at gdb.arch/amd64-disp-step-avx.S:40^M
40 vmovsd ro_var(%rip),%xmm0^M
(gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: vex2: \
continue to test_rip_vex2_end
...
The SIGILL happens when trying to execute the first avx instruction in the
executable.
I can't directly access the machine, but looking at the log for test-case
gdb.arch/i386-avx.exp, it seems that there's no avx support:
...
Breakpoint 1, main (argc=1, argv=0x7fffffffd6b8) at gdb.arch/i386-avx.c:68^M
68 if (have_avx ())^M
(gdb) print have_avx ()^M
$1 = 0^M
...
Fix this by:
- adding a gdb_caching_proc have_avx, similar to have_mpx, using the have_avx
function from gdb.arch/i386-avx.c
- using proc have_avx in both gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
and gdb/testsuite/gdb.arch/i386-avx.exp.
Tested on my x86_64-linux laptop with avx support, where both test-cases pass.
gdb/testsuite/ChangeLog:
2021-09-04 Tom de Vries <tdevries@suse.de>
PR testsuite/26950
* gdb/testsuite/gdb.arch/i386-avx.c (main): Remove call to have_avx.
(have_avx): Move ...
* gdb/testsuite/lib/gdb.exp (have_avx): ... here. New proc.
* gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp: Use have_avx.
* gdb/testsuite/gdb.arch/i386-avx.exp: Same.
On a Windows build locally, watchpoints started failing. I tracked
this down to x86_dr_low_get_addr returning an 'unsigned long'... in
this particular build, this is a 32-bit type, but the inferior is a
64-bit program.
This patch fixes the problem by changing the return type. No other
change is required, because this matches the function pointer in
struct x86_dr_low_type.
The original reproducer for PR28030 required use of a specific
compiler version - gcc-c++-11.1.1-3.fc34 is mentioned in the PR,
though it seems probable that other gcc versions might also be able to
reproduce the bug as well. This commit introduces a test case which,
using the DWARF assembler, provides a reproducer which is independent
of the compiler version. (Well, it'll work with whatever compilers
the DWARF assembler works with.)
To the best of my knowledge, it's also the first test case which uses
the DWARF assembler to provide debug info for a shared object. That
being the case, I provided more than the usual commentary which should
allow this case to be used as a template when a combo shared
library / DWARF assembler test case is required in the future.
I provide some details regarding the bug in a comment near the
beginning of locexpr-dml.exp.
This problem was difficult to reproduce; I found myself constantly
referring to the backtrace while trying to figure out what (else) I
might be missing while trying to create a reproducer. Below is a
partial backtrace which I include for posterity.
#0 internal_error (
file=0xc50110 "/ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c", line=5575,
fmt=0xc520c0 "Unexpected type field location kind: %d")
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdbsupport/errors.cc:51
#1 0x00000000006ef0c5 in copy_type_recursive (objfile=0x1635930,
type=0x274c260, copied_types=0x30bb290)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5575
#2 0x00000000006ef382 in copy_type_recursive (objfile=0x1635930,
type=0x274ca10, copied_types=0x30bb290)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5602
#3 0x0000000000a7409a in preserve_one_value (value=0x24269f0,
objfile=0x1635930, copied_types=0x30bb290)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2529
#4 0x000000000072012a in gdbscm_preserve_values (
extlang=0xc55720 <extension_language_guile>, objfile=0x1635930,
copied_types=0x30bb290)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/guile/scm-value.c:94
#5 0x00000000006a3f82 in preserve_ext_lang_values (objfile=0x1635930,
copied_types=0x30bb290)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/extension.c:568
#6 0x0000000000a7428d in preserve_values (objfile=0x1635930)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2579
#7 0x000000000082d514 in objfile::~objfile (this=0x1635930,
__in_chrg=<optimized out>)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:549
#8 0x0000000000831cc8 in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x1654580)
at /usr/include/c++/11/bits/shared_ptr_base.h:348
#9 0x00000000004e6617 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x1654580) at /usr/include/c++/11/bits/shared_ptr_base.h:168
#10 0x00000000004e1d2f in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x190bb88, __in_chrg=<optimized out>)
at /usr/include/c++/11/bits/shared_ptr_base.h:705
#11 0x000000000082feee in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x190bb80, __in_chrg=<optimized out>)
at /usr/include/c++/11/bits/shared_ptr_base.h:1154
#12 0x000000000082ff0a in std::shared_ptr<objfile>::~shared_ptr (
this=0x190bb80, __in_chrg=<optimized out>)
at /usr/include/c++/11/bits/shared_ptr.h:122
#13 0x000000000085ed7e in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x114bc00,
__p=0x190bb80) at /usr/include/c++/11/ext/new_allocator.h:168
#14 0x000000000085e88d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=...,
__p=0x190bb80) at /usr/include/c++/11/bits/alloc_traits.h:531
#15 0x000000000085e50c in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x114bc00, __position=
std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930})
at /usr/include/c++/11/bits/stl_list.h:1925
#16 0x000000000085df0e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x114bc00, __position=
std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930})
at /usr/include/c++/11/bits/list.tcc:158
#17 0x000000000085c748 in program_space::remove_objfile (this=0x114bbc0,
objfile=0x1635930)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/progspace.c:210
#18 0x000000000082d3ae in objfile::unlink (this=0x1635930)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:487
#19 0x000000000082e68c in objfile_purge_solibs ()
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:875
#20 0x000000000092dd37 in no_shared_libraries (ignored=0x0, from_tty=1)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/solib.c:1236
#21 0x00000000009a37fe in target_pre_inferior (from_tty=1)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/target.c:2496
#22 0x00000000007454d6 in run_command_1 (args=0x0, from_tty=1,
run_how=RUN_NORMAL)
at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/infcmd.c:437
I'll note a few points regarding this backtrace:
Frame #1 is where the internal error occurs. It's caused by an
unhandled case for FIELD_LOC_KIND_DWARF_BLOCK. The fix for this bug
adds support for this case.
Frame #22 - it's a partial backtrace - shows that GDB is attempting to
(re)run the program. You can see the exact command sequence that was
used for reproducing this problem in the PR (at
https://sourceware.org/bugzilla/show_bug.cgi?id=28030), but in a
nutshell, after starting the program and advancing to the appropriate
source line, GDB was asked to step into libstdc++; a "finish" command
was issued, returning a value. The fact that a value was returned is
very important. GDB was then used to step back into libstdc++. A
breakpoint was set on a source line in the library after which a "run"
command was issued.
Frame #19 shows a call to objfile_purge_solibs. It's aptly named.
Frame #7 is a call to the destructor for one of the objfile solibs; it
turned out to be the one for libstdc++.
Frames #6 thru #3 show various value preservation frames. If you look
at preserve_values() in gdb/value.c, the value history is preserved
first, followed by internal variables, followed by values for the
extension languages (python and guile).
When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
(gdb) call clear_complaints()^M
No symbol "clear_complaints" in current context.^M
(gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
...
The problem is that lto has optimized away clear_complaints, and consequently
the selftests cannot run.
Fix this by:
- using info function to detect presence of clear_complaints
- handling the absence of clear_complaints by calling untested
...
(gdb) UNTESTED: gdb.gdb/complaints.exp: \
Cannot find clear_complaints, skipping test
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-09-03 Tom de Vries <tdevries@suse.de>
* gdb.gdb/complaints.exp: Use untested if clear_complaints cannot
be found.
Values of type _Float16 and _Float16 _Complex can now be used on CPUs with
AVX512-FP16 support. Return values of those types are located in XMM0.
Compiler support for gcc and clang is in progress, see e.g.:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574117.html
gdb/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* amd64-tdep.c (amd64_classify): Classify _Float16 and
_Float16 _Complex as AMD64_SSE.
* i386-tdep.c (i386_extract_return_value): Read _Float16 and
_Float16 _Complex from xmm0.
gdb/testsuite/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdb.arch/x86-avx512fp16-abi.c: New file.
* gdb.arch/x86-avx512fp16-abi.exp: New file.
This adds support for the half datatype, FP16, to the AVX512 register printing.
gdb/ChangeLog:
2020-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* i386-tdep.c (i386_zmm_type) <v32_half>: New field.
(i386_ymm_type) <v16_half>: New field.
(i386_gdbarch_init): Add set_gdbarch_half_format.
* features/i386/64bit-avx512.xml: Add half type.
* features/i386/64bit-avx512.c: Regenerated.
* features/i386/64bit-sse.xml: Add half type.
* features/i386/64bit-sse.c: Regenerated.
gdb/testsuite/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdb.arch/x86-avx512fp16.c: New file.
* gdb.arch/x86-avx512fp16.exp: New file.
* lib/gdb.exp (skip_avx512fp16_tests): New function.
Values of type bfloat16 can also be used on 32-bit targets, which was missed
in the original enablement. This also adjusts the testcase to pass with
"unix/-m32", where only the lower 8 AVX registers are available.
gdb/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* features/i386/32bit-sse.xml: Add bfloat16 type.
* features/i386/32bit-sse.c: Regenerated.
gdb/testsuite/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdb.arch/x86-avx512bf16.exp: Only use x/z/ymm 0-7.
When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
(got interactive prompt)
FAIL: gdb.gdb/python-helper.exp: run until breakpoint at captured_main
WARNING: Couldn't test self
...
and similar in gdb.gdb/selftest.exp.
The first FAIL in more detail:
...
(gdb) break captured_main^M
Function "captured_main" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
(got interactive prompt)
...
The problem is that lto has optimized away the captured_main function
and consequently the selftests dependent on that cannot run.
Fix this by:
- using gdb_breakpoint to detect failure to set the breakpoint
- handling the failure to set a breakpoint by calling untested
- not emitting the warning if we've already got untested
such that we have:
...
(gdb) UNTESTED: gdb.gdb/python-helper.exp: Cannot set breakpoint at \
captured_main, skipping testcase.
...
gdb/testsuite/ChangeLog:
2021-09-02 Tom de Vries <tdevries@suse.de>
* lib/selftest-support.exp: Emit untested when not being able to set
breakpoint.
Fixes a few issues:
1) If you use "-fsanitize=address,undefined" in CFLAGS, the Makefile
attempt to trim off -fsanitize options left us with ",undefined".
2) ld_compile adds CFLAGS_FOR_TARGET itself, no need to pass it.
3) CFLAGS might be needed linking bootstrap test.
* Makefile.am (CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Trim off
all -fsanitize=*.
* Makefile.in: Regenerate.
* testsuite/ld-bootstrap/bootstrap.exp: Use CFLAGS when linking.
* testsuite/ld-cdtest/cdtest.exp: Use CFLAGS_FOR_TARGET when
linking.
* testsuite/ld-auto-import/auto-import.exp: Don't pass
CFLAGS_FOR_TARGET to ld_compile.
* testsuite/ld-cygwin/exe-export.exp: Likewise.
* testsuite/ld-elfvers/vers.exp: Likewise.
* testsuite/ld-elfvsb/elfvsb.exp: Likewise.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-gc/gc.exp: Likewise.
* testsuite/ld-pe/pe-compile.exp: Likewise.
* testsuite/ld-pe/pe-run.exp: Likewise.
* testsuite/ld-pe/pe-run2.exp: Likewise.
* testsuite/ld-plugin/plugin.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.
* testsuite/ld-elfcomm/elfcomm.exp: Likewise, and don't allow
nios2 testing to trash CFLAGS_FOR_TARGET.
* testsuite/ld-scripts/crossref.exp: Don't pass options in
CC_FOR_TARGET, do so in CFLAGS_FOR_TARGET instead.
* testsuite/ld-srec/srec.exp: Likewise, and for CXX.
The top level Makefile, the ld Makefile and others, define
CC_FOR_TARGET to be a compiler for the binutils target machine. This
is the compiler that should be used for almost all tests with C
source. There are _FOR_TARGET versions of CFLAGS, CXX, and CXXFLAGS
too. This was all supposed to work with the testsuite .exp files
using CC for the target compiler, and CC_FOR_HOST for the host
compiler, with the makefiles passing CC=$CC_FOR_TARGET and
CC_FOR_HOST=$CC to the runtest invocation.
One exception to the rule of using CC_FOR_TARGET is the native-only ld
bootstrap test, which uses the newly built ld to link a copy of
itself. Since the files being linked were created with the host
compiler, the boostrap test should use CC and CFLAGS, in case some
host compiler option provides needed libraries automatically.
However, bootstrap.exp used CC where it should have used CC_FOR_HOST.
I set about fixing that problem, then decided that playing games in
the makefiles with CC was a bad idea. Not only is it confusing, but
other dejagnu code knows about CC_FOR_TARGET. See dejagnu/target.exp.
So this patch gets rid of the makefile variable renaming and changes
all the .exp files to use the correct _FOR_TARGET variables.
CC_FOR_HOST and CFLAGS_FOR_HOST disappear. A followup patch will
correct bootstrap.exp to use CFLAGS, and a number of other things I
noticed.
binutils/
* testsuite/lib/binutils-common.exp (run_dump_test): Use
CC_FOR_TARGET and CFLAGS_FOR_TARGET rather than CC and CFLAGS.
ld/
* Makefile.am (check-DEJAGNU): Don't set CC to CC_FOR_TARGET
and similar. Pass variables with unchanged names. Don't set
CC_FOR_HOST or CFLAGS_FOR_HOST.
* Makefile.in: Regenerate.
* testsuite/config/default.exp: Update default CC and similar.
(compiler_supports, plug_opt): Use CC_FOR_TARGET.
* testsuite/ld-cdtest/cdtest.exp: Replace all uses of CC with
CC_FOR_TARGET, and similarly for CFLAGS, CXX and CXXFLAGS.
* testsuite/ld-auto-import/auto-import.exp: Likewise.
* testsuite/ld-cygwin/exe-export.exp: Likewise.
* testsuite/ld-elf/dwarf.exp: Likewise.
* testsuite/ld-elf/indirect.exp: Likewise.
* testsuite/ld-elf/shared.exp: Likewise.
* testsuite/ld-elfcomm/elfcomm.exp: Likewise.
* testsuite/ld-elfvers/vers.exp: Likewise.
* testsuite/ld-elfvsb/elfvsb.exp: Likewise.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-gc/gc.exp: Likewise.
* testsuite/ld-ifunc/ifunc.exp: Likewise.
* testsuite/ld-mn10300/mn10300.exp: Likewise.
* testsuite/ld-pe/pe-compile.exp: Likewise.
* testsuite/ld-pe/pe-run.exp: Likewise.
* testsuite/ld-pe/pe-run2.exp: Likewise.
* testsuite/ld-pie/pie.exp: Likewise.
* testsuite/ld-plugin/lto.exp: Likewise.
* testsuite/ld-plugin/plugin.exp: Likewise.
* testsuite/ld-scripts/crossref.exp: Likewise.
* testsuite/ld-selective/selective.exp: Likewise.
* testsuite/ld-sh/sh.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.
* testsuite/ld-srec/srec.exp: Likewise.
* testsuite/ld-undefined/undefined.exp: Likewise.
* testsuite/ld-unique/unique.exp: Likewise.
* testsuite/ld-x86-64/tls.exp: Likewise.
* testsuite/lib/ld-lib.exp: Likewise.
libctf/
* Makefile.am (check-DEJAGNU): Don't set CC to CC_FOR_TARGET.
Pass CC and CC_FOR_TARGET. Don't set CC_FOR_HOST.
* Makefile.in: Regenerate.
* testsuite/config/default.exp: Update default CC and similar.
* testsuite/lib/ctf-lib.exp (run_native_host_cmd): Use CC rather
than CC_FOR_HOST.
(run_lookup_test): Use CC_FOR_TARGET and CFLAGS_FOR_TARGET.
--enable-maintainer-mode showed a number of files needing to be
regenerated, and in the case of ld/Makefile.in that the file was
regenerated by hand. Nothing to see here really.
ld/
* Makefile.am (ALL_64_EMULATION_SOURCES): Sort haiku entry.
* Makefile.in: Regenerate.
* po/BLD-POTFILES.in: Regenerate.
libctf/
* configure: Regenerate.
zlib/
* configure: Regenerate.
to match GNU ld.
gold/
* archive.cc (Library_base::should_include_member): Don't handle
--export-dynamic-symbol.
* symtab.cc (Symbol_table::do_add_undefined_symbols_from_command_line):
Likewise.
PR 28292
gas * config/tc-v850.c (handle_lo16): Also accept
BFD_RELOC_V850_LO16_SPLIT_OFFSET.
* testsuite/gas/v850/split-lo16.s: Add extra line.
* testsuite/gas/v850/split-lo16.d: Update expected disassembly.
opcodes * v850-opc.c (D16): Use BFD_RELOC_V850_LO16_SPLIT_OFFSET in place
of BFD_RELOC_16.
.symtab_shndx section contents is an array, one entry for each symbol
in .symtab, present when the number of symbols exceeds a little less
than 64k. Since the mapping is 1-1 with symbols there is no need to
keep both dest_index and destshndx_index in elf_sym_strtab. Instead,
just make sure that the shndx pointers to the swap functions are kept
NULL when .symtab_shndx does not exist. Also, strtabcount in the
linker's elf hash table is incremented in lock-step with the output
symcount, so that can disappear too.
This defines a couple of macros used to avoid ubsan complaints about
calculations involving NULL pointers. PTR_ADD should be used in the
case where it is known that the offset is always zero with a NULL
pointer, and you'd like to know if a non-zero offset is ever used.
NPTR_ADD should be rarely used, but is defined for cases where a
non-zero offset is expected and should be ignored if the pointer is
NULL.
bfd/
* bfd-in.h (PTR_ADD, NPTR_ADD): Define.
* bfd-in2.h: Regenerate.
* elf-eh-frame.c (adjust_eh_frame_local_symbols): Avoid NULL
pointer calculations.
* elflink.c (_bfd_elf_strip_zero_sized_dynamic_sections): Likewise.
(bfd_elf_add_dt_needed_tag, elf_finalize_dynstr): Likewise.
(elf_link_add_object_symbols, elf_link_input_bfd): Likewise.
(bfd_elf_final_link, bfd_elf_gc_record_vtinherit): Likewise.
binutils/
* objdump.c (disassemble_section): Use PTR_ADD for rel_ppend.
Current ubsan complains on every use of __PTR_ALIGN (when ptrdiff_t is
as large as a pointer), due to making calculations relative to a NULL
pointer. This patch avoids the problem by extracting out and
simplifying __BPTR_ALIGN for the usual case. I've continued to use
ptrdiff_t here, where it might be better to throw away __BPTR_ALIGN
entirely and just assume uintptr_t exists.
* obstack.h (__PTR_ALIGN): Expand and simplify __BPTR_ALIGN
rather than calculating relative to a NULL pointer.
[ Using $build for /home/vries/gdb_versions/devel/build to make things a bit
more readable. ]
When using make check// to run test-case gdb.dwarf2/fission-base.exp:
...
( cd $build/gdb; make check//unix RUNTESTFLAGS="fission-base.exp" )
...
we run into:
...
(gdb) file \
$build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base^M
Reading symbols from \
$build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base...^M
warning: Could not find DWO CU \
$build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo \
(0x807060504030201) referenced by CU at offset 0xc7 [in module \
$build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base]^M
...
The problem is that the executable refers to the dwo file using path name
$build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo,
while the actual dwo file is at
$build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base.dwo.
This is caused by this trick in fission-base.S:
...
#define XSTR(s) STR(s)
#define STR(s) #s
...
.asciz XSTR(DWO) # DW_AT_GNU_dwo_name
...
and:
...
$ echo | gcc -E -dD - | grep "define unix"
...
I used this trick to avoid doing additional_flags=-DDWO=\"$dwo\", since I was
concerned that there could be quoting issues.
However, I've found other uses of this pattern, f.i. in
gdb/testsuite/gdb.base/corefile-buildid.exp:
...
additional_flags=-DSHLIB_NAME=\"$dlopen_lib\"]
...
So, fix this by:
- using additional_flags=-DDWO=\"$dwo\" and
- using plain DWO instead of XSTR(DWO)
Likewise in other gdb.dwarf2/fission*.exp test-cases.
Tested on x86_64-linux, using make check//unix.
gdb/testsuite/ChangeLog:
2021-09-01 Tom de Vries <tdevries@suse.de>
PR testsuite/28298
* gdb.dwarf2/fission-base.S: Use DWO instead of XSTR(DWO).
* gdb.dwarf2/fission-loclists-pie.S: Same.
* gdb.dwarf2/fission-loclists.S: Same.
* gdb.dwarf2/fission-reread.S: Same.
* gdb.dwarf2/fission-base.exp: Use additional_flags=-DDWO=\"$dwo\".
* gdb.dwarf2/fission-loclists-pie.exp: Same.
* gdb.dwarf2/fission-loclists.exp: Same.
* gdb.dwarf2/fission-reread.exp: Same.
On openSUSE Tumbleweed I ran into:
...
(gdb) ptype outstring_func.part^M
No symbol "outstring_func" in current context.^M
(gdb) FAIL: gdb.fortran/call-no-debug.exp: ptype outstring_func.part
...
while on openSUSE Leap 15.2 I have instead:
...
(gdb) ptype string_func_^M
type = <unknown return type> ()^M
(gdb) PASS: gdb.fortran/call-no-debug.exp: ptype string_func_
...
The difference is caused by the result for "info function string_func", which
is this for the latter:
...
(gdb) info function string_func^M
All functions matching regular expression "string_func":^M
^M
Non-debugging symbols:^M
0x000000000040089c string_func_^M
...
but this for the former:
...
(gdb) info function string_func^M
All functions matching regular expression "string_func":^M
^M
Non-debugging symbols:^M
0x00000000004012bb string_func_^M
0x00007ffff7bac5b0 outstring_func.part^M
0x00007ffff7bb1a00 outstring_func.part^M
...
The extra symbols are part of glibc:
...
$ nm /lib64/libc.so.6 | grep string_func
00000000000695b0 t outstring_func.part.0
000000000006ea00 t outstring_func.part.0
...
If glibc debug info is installed, we get instead:
...
(gdb) info function string_func^M
All functions matching regular expression "string_func":^M
^M
File /usr/src/debug/glibc-2.33-9.1.x86_64/stdio-common/vfprintf-internal.c:^M
236: static int outstring_func(int, size_t, const unsigned int *, FILE *);^M
^M
File vfprintf-internal.c:^M
236: static int outstring_func(int, size_t, const unsigned char *, FILE *);^M
^M
Non-debugging symbols:^M
0x00000000004012bb string_func_^M
...
and the FAIL doesn't trigger.
Fix this by calling "info function string_func" before starting the exec, such
that only symbols of the exec are taken into account.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-09-01 Tom de Vries <tdevries@suse.de>
* gdb.fortran/call-no-debug.exp: Avoid shared lib symbols for
find_mangled_name calls.
Remove breakpoint_find_if, replace its sole usage with using
all_breakpoints directly instead. At the same time, change return
types to use bool.
Change-Id: I9ec392236b4804b362d16ab563330b9c07311106
The .insn directive can let users use their own instructions, or
some new instruction, which haven't supported in the old binutils.
For example, if users want to use sifive cache instruction, they
cannot just write "cflush.d1.l1" in the assembly code, they should
use ".insn i SYSTEM, 0, x0, x10, -0x40". But the .insn directive
may not easy to use for some cases, and not so friendly to users.
Therefore, I believe most of the users will use ".word 0xfc050073",
to encode the instructions directly, rather than use .insn. But
once we have supported the mapping symbols, the .word directives
are marked as data, so disassembler won't dump them as instructions
as usual. I have discussed this with Kito many times, we all think
extend the .insn direcitve to support the hardcode encoding, is the
easiest way to resolve the problem. Therefore, there are two more
.insn formats are proposed as follows,
(original) .insn <type>, <operand1>, <operand2>, ...
.insn <insn-length>, <value>
.insn <value>
The <type> is string, and the <insn-length> and <value> are constants.
gas/
* config/tc-riscv.c (riscv_ip_hardcode): Similar to riscv_ip,
but assembles an instruction according to the hardcode values
of .insn directive.
* doc/c-riscv.texi: Document two new .insn formats.
* testsuite/gas/riscv/insn-fail.d: New testcases.
* testsuite/gas/riscv/insn-fail.l: Likewise.
* testsuite/gas/riscv/insn-fail.s: Likewise.
* testsuite/gas/riscv/insn.d: Updated.
* testsuite/gas/riscv/insn.s: Likewise.
