Mike Frysinger [Fri, 7 May 2021 04:31:05 +0000 (00:31 -0400)]
sim: m32c: clean up various warnings
A random grab bag of minor fixes to enable -Werror for this port.
Check the return values of read & write calls and issue warnings when
they fail.
Fixup funky pointer math as the compiler doesn't like ++ on void*.
Handle short reads with fread().
Mike Frysinger [Fri, 7 May 2021 03:51:10 +0000 (23:51 -0400)]
sim: m68hc11: warn when emul_write fails
Not sure what we should do here when this fails, so just emit a warning
for now to satisfy unused result compiler warnings. We can see if any
users actually notice here.
The 'handle_v_attach', 'handle_v_run', and 'handle_v_kill' functions'
return values are unused. They indicate error/success result by
putting packets. Make the functions void.
Tested by rebuilding.
gdbserver/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* server.cc (handle_v_attach)
(handle_v_run)
(handle_v_kill): Make void.
Stafford Horne [Thu, 6 May 2021 11:51:25 +0000 (20:51 +0900)]
or1k: Support large plt_relocs when generating plt entries
The current PLT generation code will generate invalid code when the PLT
relocation offset exceeds 64k. This fixes the issue by detecting large
plt_reloc offsets and generare code sequences to create larger plt
relocations.
The "large" plt code needs 2 extra instructions to create 32-bit offsets.
bfd/ChangeLog:
PR 27746
* elf32-or1k.c (PLT_ENTRY_SIZE_LARGE, PLT_MAX_INSN_COUNT,
OR1K_ADD, OR1K_ORI): New macros to help with plt creation.
(elf_or1k_link_hash_table): New field plt_count.
(elf_or1k_link_hash_entry): New field plt_index.
(elf_or1k_plt_entry_size): New function.
(or1k_write_plt_entry): Update to support variable size PLTs.
(or1k_elf_finish_dynamic_sections): Use new or1k_write_plt_entry
API.
(or1k_elf_finish_dynamic_symbol): Update to write large PLTs
when needed.
(allocate_dynrelocs): Use elf_or1k_plt_entry_size to account for
PLT size.
ld/ChangeLog:
PR 27746
testsuite/ld-or1k/or1k.exp (or1kplttests): Add tests for linking
along with gotha() relocations.
testsuite/ld-or1k/gotha1.dd: New file.
testsuite/ld-or1k/gotha1.s: New file.
testsuite/ld-or1k/gotha2.dd: New file.
testsuite/ld-or1k/gotha2.s: New file
testsuite/ld-or1k/pltlib.s (x): Define size to avoid link
failure.
Stafford Horne [Thu, 6 May 2021 11:51:25 +0000 (20:51 +0900)]
or1k: Avoid R_OR1K_GOT16 overflow failures in presence of R_OR1K_GOT_AHI16
Now that we support R_OR1K_GOT_AHI16 we can relax the R_OR1K_GOT16
overflow validation check if the section has R_OR1K_GOT_AHI16.
We cannot simple disable R_OR1K_GOT16 overflow validation as there will
still be binaries that will have only R_OR1K_GOT16. The
R_OR1K_GOT_AHI16 relocation will only be added by GCC when building with
the option -mcmodel=large.
This assumes that R_OR1K_GOT_AHI16 will come before R_OR1K_GOT16, which
is the code pattern that will be emitted by GCC.
bfd/ChangeLog:
PR 21464
* elf32-or1k.c (or1k_elf_relocate_section): Relax R_OR1K_GOT16
overflow check if we have R_OR1K_GOT_AHI16 followed by
R_OR1K_GOT16.
Stafford Horne [Thu, 6 May 2021 11:51:24 +0000 (20:51 +0900)]
or1k: Implement relocation R_OR1K_GOT_AHI16 for gotha()
The gotha() relocation mnemonic will be outputted by OpenRISC GCC when
using the -mcmodel=large option. This relocation is used along with
got() to generate 32-bit GOT offsets. This increases the previous GOT
offset limit from the previous 16-bit (64K) limit.
This is needed on large binaries where the GOT grows larger than 64k.
This failure happens while writing out PLT entries, there is a check
"BFD_ASSERT (h->dynindx != -1)" to confirm all plt entries have dynamic
symbol attributes. This was failing for symbols that were
"forced_local" in previous linking code.
The fix adds logic to or1k_elf_adjust_dynamic_symbol to identify
"forced_local" symbols and exclude them from the the PLT.
bfd/ChangeLog:
PR 27624
* elf32-or1k.c (or1k_elf_adjust_dynamic_symbol): Change
condition used to cleanup plt entries to cleanup forced local
entries.
This turns out to be because GDB calls event_location_to_string on the
breakpoints location, and watchpoint breakpoints don't have a
location.
This commit resolves the crash by just skipping the printing of the
location if the breakpoint doesn't have one.
Potentially, we could improve on this by printing details about what
the watchpoint is watching, however, I'm considering this a possible
future enhancement, this commit focuses just on having GDB not crash.
gdb/ChangeLog:
* guile/scm-breakpoint.c (bpscm_print_breakpoint_smob): Only print
breakpoint locations when the breakpoint actually has a location.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-breakpoint.exp (test_watchpoints): Print the
watchpoint object before and after registering it with GDB.
Andrew Burgess [Thu, 6 May 2021 09:37:04 +0000 (10:37 +0100)]
gdb/testsuite: use proc_with_prefix in gdb.guile/scm-breakpoint.exp
Convert gdb.guile/scm-breakpoint.exp to use proc_with_prefix instead
of using nested with_test_prefix calls. Allows a level of indentation
to be removed from most of the test procs.
There were two procs that didn't use with_test_prefix, but I converted
them to be proc_with_prefix anyway, for consistency.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-breakpoint.exp (test_bkpt_basic): Convert to
'proc_with_prefix', remove use of 'with_test_prefix', and
reindent.
(test_bkpt_deletion): Likewise.
(test_bkpt_cond_and_cmds): Likewise.
(test_bkpt_invisible): Likewise.
(test_watchpoints): Likewise.
(test_bkpt_internal): Likewise.
(test_bkpt_eval_funcs): Likewise.
(test_bkpt_registration): Likewise.
(test_bkpt_address): Convert to 'proc_with_prefix'.
(test_bkpt_probe): Likewise.
gdb/mi: add a '--force' flag to the '-break-condition' command
Add a '--force' flag to the '-break-condition' command to be
able to force conditions.
gdb/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* mi/mi-cmd-break.c (mi_cmd_break_condition): New function.
* mi/mi-cmds.c: Change the binding of "-break-condition" to
mi_cmd_break_condition.
* mi/mi-cmds.h (mi_cmd_break_condition): Declare.
* breakpoint.h (set_breakpoint_condition): Declare a new
overload.
* breakpoint.c (set_breakpoint_condition): New overloaded function
extracted out from ...
(condition_command): ... this.
* NEWS: Mention the change.
gdb/testsuite/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/mi-break.exp (test_forced_conditions): Add a test
for the -break-condition command's "--force" flag.
gdb/doc/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (GDB/MI Breakpoint Commands): Mention the
'--force' flag of the '-break-condition' command.
gdb/mi: add a '--force-condition' flag to the '-break-insert' cmd
Add a '--force-condition' flag to the '-break-insert' command to be
able to force conditions. Because the '-dprintf-insert' command uses
the same mechanism as the '-break-insert' command, it obtains the
'--force-condition' flag, too.
gdb/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Recognize the
'--force-condition' flag to force the condition in the
'-break-insert' and '-dprintf-insert' commands.
* NEWS: Mention the change.
gdb/testsuite/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/mi-break.exp (test_forced_conditions): New proc that
is called by the test.
gdb/doc/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (GDB/MI Breakpoint Commands): Mention the
'--force-condition' flag of the '-break-insert' and
'-dprintf-insert' commands.
Nick Alcock [Thu, 6 May 2021 08:30:58 +0000 (09:30 +0100)]
libctf, ld: fix test results for upstream GCC
The tests currently in binutils are aimed at the original GCC-based
implementation of CTF, which emitted CTF directly from GCC's internal
representation. The approach now under review emits CTF from DWARF,
with an eye to eventually doing this for all non-DWARF debuginfo-like
formats GCC supports. It also uses a different flag to enable
CTF emission (-gctf rather than -gt).
Adjust the testsuite accordingly.
Given that the ld testsuite results are dependent on type ordering,
which we do not guarantee at all, it's amazing how little changes. We
see a few type ordering differences, slices change because the old GCC
was buggy (slices were emitted "backwards", from the wrong end of the
machine word) and its expected results were wrong, and GCC now emits the
underlying integral type for enumerated types, though CTF has no way to
record this yet (coming in v4).
GCC also now emits even hidden symbols into the symtab (and thus
symtypetab), so one symtypetab test changes its expected results
slightly to compensate.
Also add tests for the CTF_K_UNKNOWN nonrepresentable type: this
couldn't be done before now since the only GCC that emits CTF_K_UNKNOWN
for nonrepresentable types is the new one.
ld/ChangeLog
2021-05-06 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/ctf.exp: Use -gctf, not -gt.
* testsuite/lib/ld-lib.exp: Likewise.
* testsuite/ld-ctf/nonrepresentable-1.c: New test for nonrepresentable types.
* testsuite/ld-ctf/nonrepresentable-2.c: Likewise.
* testsuite/ld-ctf/nonrepresentable.d: Likewise.
* testsuite/ld-ctf/array.d: Larger type section.
* testsuite/ld-ctf/data-func-conflicted.d: Likewise.
* testsuite/ld-ctf/enums.d: Likewise.
* testsuite/ld-ctf/conflicting-enums.d: Don't compare types.
* testsuite/ld-ctf/cross-tu-cyclic-conflicting.d: Changed type order.
* testsuite/ld-ctf/cross-tu-noncyclic.d: Likewise.
* testsuite/ld-ctf/slice.d: Adjust for improved slice emission.
libctf/ChangeLog
2021-05-06 Nick Alcock <nick.alcock@oracle.com>
* testsuite/lib/ctf-lib.exp: Use -gctf, not -gt.
* testsuite/libctf-regression/nonstatic-var-section-ld-r.lk:
Hidden symbols now get into the symtypetab anyway.
Nick Alcock [Thu, 6 May 2021 08:30:58 +0000 (09:30 +0100)]
libctf, include: support an alternative encoding for nonrepresentable types
Before now, types that could not be encoded in CTF were represented as
references to type ID 0, which does not itself appear in the
dictionary. This choice is annoying in several ways, principally that it
forces generators and consumers of CTF to grow special cases for types
that are referenced in valid dicts but don't appear.
Allow an alternative representation (which will become the only
representation in format v4) whereby nonrepresentable types are encoded
as actual types with kind CTF_K_UNKNOWN (an already-existing kind
theoretically but not in practice used for padding, with value 0).
This is backward-compatible, because CTF_K_UNKNOWN was not used anywhere
before now: it was used in old-format function symtypetabs, but these
were never emitted by any compiler and the code to handle them in libctf
likely never worked and was removed last year, in favour of new-format
symtypetabs that contain only type IDs, not type kinds.
In order to link this type, we need an API addition to let us add types
of unknown kind to the dict: we let them optionally have names so that
GCC can emit many different unknown types and those types with identical
names will be deduplicated together. There are also small tweaks to the
deduplicator to actually dedup such types, to let opening of dicts with
unknown types with names work, to return the ECTF_NONREPRESENTABLE error
on resolution of such types (like ID 0), and to print their names as
something useful but not a valid C identifier, mostly for the sake of
the dumper.
Tests added in the next commit.
include/ChangeLog
2021-05-06 Nick Alcock <nick.alcock@oracle.com>
* ctf.h (CTF_K_UNKNOWN): Document that it can be used for
nonrepresentable types, not just padding.
* ctf-api.h (ctf_add_unknown): New.
libctf/ChangeLog
2021-05-06 Nick Alcock <nick.alcock@oracle.com>
* ctf-open.c (init_types): Unknown types may have names.
* ctf-types.c (ctf_type_resolve): CTF_K_UNKNOWN is as
non-representable as type ID 0.
(ctf_type_aname): Print unknown types.
* ctf-dedup.c (ctf_dedup_hash_type): Do not early-exit for
CTF_K_UNKNOWN types: they have real hash values now.
(ctf_dedup_rwalk_one_output_mapping): Treat CTF_K_UNKNOWN types
like other types with no referents: call the callback and do not
skip them.
(ctf_dedup_emit_type): Emit via...
* ctf-create.c (ctf_add_unknown): ... this new function.
* libctf.ver (LIBCTF_1.2): Add it.
Tom de Vries [Wed, 5 May 2021 13:13:17 +0000 (15:13 +0200)]
[gdb/testsuite] Fix timeout in gdb.threads/detach-step-over.exp with readnow
When running test-case gdb.threads/detach-step-over.exp with target board
readnow, I run into:
...
Reading symbols from /lib64/libc.so.6...^M
Reading symbols from \
/usr/lib/debug/lib64/libc-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
Expanding full symbols from \
/usr/lib/debug/lib64/libc-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
FAIL: gdb.threads/detach-step-over.exp: \
breakpoint-condition-evaluation=host: target-non-stop=on: non-stop=on: \
displaced=off: iter 2: attach (timeout)
...
Fix this by doing exp_continue when encountering the "Reading symbols" or
"Expanding full symbols" lines.
This is still fragile and times out with a higher load, similated f.i. by
stress -c 5. Fix that by using a timeout factor of 2.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-05-05 Tom de Vries <tdevries@suse.de>
* gdb.threads/detach-step-over.exp: Do exp_continue when encountering
"Reading symbols" or "Expanding full symbols" lines. Using timeout
factor of 2 for attach.
Tom de Vries [Wed, 5 May 2021 07:07:27 +0000 (09:07 +0200)]
[gdb/testsuite] Fix gdb.threads/fork-plus-threads.exp with readnow
When running test-case gdb.threads/fork-plus-threads.exp with target board
readnow, I run into:
...
[LWP 9362 exited]^M
[New LWP 9365]^M
[New LWP 9363]^M
[New LWP 9364]^M
FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \
inferior 1 exited (timeout)
...
There is code in the test-case to prevent timeouts with readnow:
...
-re "Thread \[^\r\n\]+ exited" {
# Avoid timeout with check-read1
exp_continue
}
-re "New Thread \[^\r\n\]+" {
# Avoid timeout with check-read1
exp_continue
}
...
but this doesn't trigger because we get LWP rather than Thread.
Fix this by making these regexps accept LWP as well.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-05-05 Tom de Vries <tdevries@suse.de>
* gdb.threads/fork-plus-threads.exp: Handle "New LWP <n>" and
"LWP <n> exited" messages.
Mike Frysinger [Wed, 5 May 2021 02:56:31 +0000 (22:56 -0400)]
sim: rl78: clean up various warnings
A random grab bag of minor fixes to enable -Werror for this port.
Fix local prototypes for a bunch of functions (e.g. adding static).
Add missing includes for missing prototypes.
Move local variable decls from the middle of functions to the top
of the scope.
Fix a logic error when processing commands where p was reassigned
to cmd and then has its leading whitespace scanned a 2nd time.
Handle short reads with fread().
Simon Marchi [Wed, 5 May 2021 02:19:05 +0000 (22:19 -0400)]
gdb: update Type.fields doc based on actual GDB behavior
I noticed two errors in the Type.fields documentation:
1. It is possible to call `fields` on an array type, in which case it
returns one field representing the array's range. It is not
mentioned.
2. When calling `fields` on a type that doesn't have fields (by nature,
like an int), GDB raises a TypeError. It does not return an empty
sequence, as currently documented.
Fix these, and change the text into a bullet list. I find it easier to
read than one big paragraph.
The first issue is already tested in gdb.python/py-type.exp, but the
second one doesn't seem tested. Add a test in gdb.python/py-type.exp
for it.
gdb/doc/ChangeLog:
* python.texi (Types In Python): Re-organize Type.fields doc.
Mention handling of array types. Correct doc for when calling
the method on another type.
gdb/testsuite/ChangeLog:
* gdb.python/py-type.exp (test_fields): Test calling fields on
an int type.
Mike Frysinger [Tue, 4 May 2021 12:39:17 +0000 (08:39 -0400)]
sim: mips: always enable device models
There's no need to restrict these to only specific targets as the user
can select them at runtime if they want them. Always build them so we
can improve build coverage too.
Mike Frysinger [Tue, 4 May 2021 12:33:24 +0000 (08:33 -0400)]
sim: remove sys/times.h in most places
The v850 port used this, and then it got copied to other ports even
though it wasn't needed. Clean it up to avoid portability issues on
platforms not providing this (e.g. mingw64 for Windows).
Mike Frysinger [Tue, 27 Apr 2021 03:14:11 +0000 (23:14 -0400)]
sim: microblaze: hook up libgloss syscalls
When in the virtual environment, have brki 8 trigger libgloss syscalls
like other ports. This also matches the ABI that Linux uses for its
syscalls (ignoring the syscall table differences).
* testsuite/ld-powerpc/empty.s: New file.
* testsuite/ld-powerpc/undefweak.d,
* testsuite/ld-powerpc/undefweak.s: New testcase.
* testsuite/ld-powerpc/powerpc.exp: Run it.
Tom Tromey [Tue, 4 May 2021 14:45:46 +0000 (08:45 -0600)]
Fix igen build
The igen build fails for me like:
gcc -g -O2 -c ../../binutils-gdb/sim/igen/igen.c -o igen/igen.o
In file included from ../../binutils-gdb/sim/igen/igen.c:26:
../../binutils-gdb/sim/igen/lf.h:22:10: fatal error: ansidecl.h: No such file or directory
This patch fixes the problem by arranging for igen to find the
libiberty includes.
This seems slightly hacky to me, because libiberty is not a "build"
library, so it can't be linked against. However, since igen currently
only includes the header, it seems relatively safe.
2021-05-04 Tom Tromey <tromey@adacore.com>
* Makefile.in: Rebuild.
* Makefile.am (AM_CPPFLAGS): New variable.
Mike Frysinger [Sat, 1 May 2021 22:00:27 +0000 (18:00 -0400)]
gnulib: import getline
We use getline in sim today which breaks on older systems that are
not compliant with the latest POSIX standard. For example, mingw64
for Windows omits getline so we fail to build there.
The value that we get for the upper bound of a flexible array member
declared with a "0" size is 0 with gcc <= 8 and is -1 for gcc >= 9.
This is due to different debug info. For this member, gcc 8 does:
Ideally, GDB would present a consistent and documented value for an
array member declared with size 0, regardless of how the debug info
looks like. But for now, just change the test to accept the two
values, to get rid of the failure and make the test in sync
I also realized (by looking at the py-type.exp test) that calling the
fields method on an array type yields one field representing the "index"
of the array. The type of that field is of type range
(gdb.TYPE_CODE_RANGE). When calling `.range()` on that range type, it
yields the same range tuple as when calling `.range()` on the array type
itself. For completeness, add some tests to access the range tuple
through that range type as well.
gdb/testsuite/ChangeLog:
* gdb.python/flexible-array-member.exp: Adjust expected range
value for member declared with 0 size. Test accessing range
tuple through range type.
Nick Clifton [Tue, 4 May 2021 13:29:04 +0000 (14:29 +0100)]
Define bfd_realloc(ptr,0) to return allocated memory, whilst bfd_realloc_or_free(ptr,0) frees ptr.
* libbfd.c (bfd_malloc): Provide some documenation. Treat a size
of 0 as 1.
(bfd_realloc): Likewise.
(bfd_zmalloc): Likewise.
(bfd_realloc_or_free): Provide some documentation. Treat a size
of 0 as a request to free.
* libbfd-in.h (bfd_realloc): Remove prototype.
(bfd_realloc_or_free): Remove prototype.
(bfd_zmalloc): Remove prototype.
* libbfd.h: Regenerate.
Mike Frysinger [Sat, 1 May 2021 21:16:23 +0000 (17:16 -0400)]
sim: add support for build-time ar & ranlib
This is needed when building for a target whose ar & ranlib are
incompatible with the current build system. For example, building
for Windows on a Linux system.
Then manually import the automake rule for libigen.a, but tweak the
tool variables to use the FOR_BUILD variants.
Mike Frysinger [Tue, 4 May 2021 03:27:16 +0000 (23:27 -0400)]
sim: clean up bfd_vma printing
A lot of this code predates the bfd_vma format define, so we have a
random mix of casts to known types so we can printf the value. Use
the BFD_VMA_FMT that now exists to simplify and reliability output
across different build configs.
Tom de Vries [Tue, 4 May 2021 08:26:16 +0000 (10:26 +0200)]
[gdb/guile] Don't allow libguile to change libgmp mem fns
Since gdb commit 880ae75a2b7 "gdb delay guile initialization until
gdbscm_finish_initialization" I'm running into:
...
(gdb) print My_Var > 10.0^M
free(): invalid pointer^M
ERROR: GDB process no longer exists
GDB process exited with wait status 5995 exp9 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.ada/fixed_cmp.exp: gnat_encodings=all: print My_Var > 10.0
...
The problem is that both gdb and libguile try to set the libgmp memory functions,
and since the gdb commit the ones from libguile are effective, which results
in gdb freeing some memory in a way that is not compatible with the way that
memory was actually allocated.
The fact that libguile tries to set the libgmp memory functions is a bug which
should be fixed starting version v3.0.6.
Meanwhile, work around this in gdb by not allowing libguile to set the libgomp
memory functions.
Tom Tromey [Mon, 3 May 2021 14:57:46 +0000 (08:57 -0600)]
Fix x86_64 mingw build
PR build/27807 points out that my recent changes to the Windows port
missed a spot in win32-i386-low.cc -- a call to
win32_Wow64GetThreadContext remained, causing link errors in
gdbserver. This happened because I tested an i686 build, but this
code is only used on an x86_64 build.
This patch fixes the bug. I am checking it in.
gdbserver/ChangeLog
2021-05-03 Tom Tromey <tromey@adacore.com>
PR build/27807:
* win32-i386-low.cc (i386_get_thread_context): Call
Wow64GetThreadContext, not win32_Wow64GetThreadContext.
Simon Marchi [Mon, 3 May 2021 14:54:08 +0000 (10:54 -0400)]
sim: add ATTRIBUTE_PRINTF / ATTRIBUTE_NULL_PRINTF where necessary
I finally got the all-targets sim building with Clang, these are all the
instances where an ATTRIBUTE_PRINTF or ATTRIBUTE_NULL_PRINTF attribute
needed to be added to avoid errors like:
/home/simark/src/binutils-gdb/sim/aarch64/../common/sim-profile.c:464:19: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
vfprintf (fp, fmt, ap);
^~~
There are more fixes needed to get everything building, but adding these
attributes is trivial enough, so I send them all in a single patch.
Adding the format attributes introduces some format string errors when
building with GCC (because now format strings are checked), so
corresponding changes are needed to avoid breaking the build. Other
than simple format string specified changes, there is this one:
/home/simark/src/binutils-gdb/sim/aarch64/../common/hw-events.c: In function 'hw_event_queue_schedule':
/home/simark/src/binutils-gdb/sim/aarch64/../common/hw-events.c:95:15: error: too many arguments for format [-Werror=format-extra-args]
95 | NULL, dummy);
| ^~~~~
We can fix it and avoid using a dummy variable by simply calling
hw_event_queue_schedule_tracef instead of
hw_event_queue_schedule_vtracef.
sim/arm/ChangeLog:
* armdefs.h (ARMul_ConsolePrint): Use format attribute.
* wrapper.c (op_printf): Likewise.
sim/bfin/ChangeLog:
* interp.c (sim_open): Adjust format string specifier.
Jan Beulich [Mon, 3 May 2021 11:28:30 +0000 (13:28 +0200)]
x86: allow @secrel32 also in data definitions
Now that lex_got() is uniform for all targets using it, permit COFF
targets to also use @secrel32 with, in particular, .long. This is more
natural than the custom .secrel32 directive, and also allows more
flexibility (the "+six" form of the two added test lines doesn't work
with a .secrel32 equivalent, in that it silently produces an unintended
relocation type).
As an extra benefit this also makes sure that data definitions in Intel
syntax mode would get treated like they do for e.g. ELF targets.
Jan Beulich [Mon, 3 May 2021 11:26:41 +0000 (13:26 +0200)]
x86: fold both instances of lex_got()
I see no reason at all for us to carry two copies of almost identical
code. The differences, apart from the table entries, are benign. And
the #ifdef-ary doesn't really get any worse.
Jan Beulich [Mon, 3 May 2021 11:25:12 +0000 (13:25 +0200)]
x86: don't request useless overflow checking
Relocations with a bitsize matching the architecture's address width
can't usefully use an overflow checking approach other than "dont" or
"signed": All others involve perhaps complex calculations in
_bfd_relocate_contents() (or, not as severe, in bfd_check_overflow())
without ever finding anything to complain about - because of the address
width masking applied. Avoid this unnecessary overhead and switch all
such reloc types to "dont".
Note that "signed" checking with rela relocations (i.e. x86-64 here) is
only going to be useful if the addend actually got passed to
_bfd_relocate_contents() (and maybe others) instead of bogusly adding in
prior section contents (which apparently is assumed to be zero, and
hence again no overflow would ever be detected). See
https://sourceware.org/pipermail/binutils/2021-April/116164.html.
Andrew Burgess [Thu, 29 Apr 2021 09:11:35 +0000 (10:11 +0100)]
gdb/testsuite: update expected results in gdb.python/py-startup-opt.exp
The test gdb.python/py-startup-opt.exp checks the behaviour of GDB's:
set python dont-write-bytecode on
This flag (when on) stops Python creating .pyc files. The test first
checks that .pyc files will be created, then turns this option on and
checks .pyc files will not be created.
However, if the user has PYTHONDONTWRITEBYTECODE set in their
environment then this will prevent Python from creating .pyc files, as
such the first test, that .pyc files are being created, currently
fails.
We could unset PYTHONDONTWRITEBYTECODE, however, until Python 3.8
there is no way to control where Python writes the .pyc files. As the
GDB developer clearly doesn't want .pyc files created in their
file-system it feels wrong to silently unset this environment
variable.
My proposal then, is that we just spot when this environment variable
is set and adjust the expected results. My hope is that across all
GDB developers some will be running with PYTHONDONTWRITEBYTECODE
unset, so this feature will be fully tested at least some of the time.
gdb/testsuite/ChangeLog:
PR testsuite/27788
* gdb.python/py-startup-opt.exp (test_python_settings): Change the
expected results when environment variable PYTHONDONTWRITEBYTECODE
is set.
Alan Modra [Mon, 3 May 2021 02:58:46 +0000 (12:28 +0930)]
PPC: undefweak dynamic relocs
This makes the default for ppc to keep dynamic relocs on undefweak
symbols when the code won't cause DT_TEXTREL (for instance when -fPIE
or -fPIC). If ld is given -z dynamic-undefined-weak then dynamic
relocations will be created for non-PIC at the expense of possibly
causing DT_TEXTREL to be set on ppc32. Note that DT_TEXTREL and GNU
indirect functions are incompatible.
* elf32-ppc.c (allocate_dynrelocs): Keep dyn_relocs for undefweak
symbols when -z dynamic-undefined-weak or when there are no
dynamic relocs in read-only sections and -z nodynamic-undefined-weak
is not given.
* elf64-ppc.c (allocate_dynrelocs): Likewise.
Alan Modra [Mon, 3 May 2021 00:33:06 +0000 (10:03 +0930)]
PPC: ensure_undef_dynamic on weak undef only in plt
It's slightly weird to have a call to a weak function not protected by
a test of that function being non-NULL, but the non-NULL test might be
covered by a test of another function. For example:
if (func1)
{
func1 ();
func2 ();
}
where func2 is known to exist if func1 exists.
* elf32-ppc.c (allocate_dynrelocs): Call ensure_undef_dynamic for
weak undefined symols that only appear on PLT relocs.
* elf64-ppc.c (allocate_dynrelocs): Likewise.
Simon Marchi [Sun, 2 May 2021 15:04:58 +0000 (11:04 -0400)]
sim: add default cases to two switches in sim-options.c
This is the next compilation error I hit when I build all targets with
Clang:
/home/simark/src/binutils-gdb/sim/aarch64/../common/sim-options.c:234:12: error: no case matching constant switch condition '0' [-Werror] switch (WITH_ENVIRONMENT)
^~~~~~~~~~~~~~~~ ./config.h:215:26: note: expanded from macro 'WITH_ENVIRONMENT'
#define WITH_ENVIRONMENT ALL_ENVIRONMENT ^~~~~~~~~~~~~~~
/home/simark/src/binutils-gdb/sim/aarch64/../common/sim-options.c:276:15: error: no case matching constant switch condition '0' [-Werror] switch (WITH_ALIGNMENT)
^~~~~~~~~~~~~~ /home/simark/src/binutils-gdb/sim/aarch64/../common/sim-config.h:220:24: note: expanded from macro 'WITH_ALIGNMENT'
#define WITH_ALIGNMENT 0
^
This is a little bit special because these are switches on compile-time
value. But regardless, the idea is that we logically can't reach the
switches if WITH_ENVIRONMENT == 0 or WITH_ALIGNMENT == 0, so the code is
correct.
In addition to getting rid of the compiler warning, adding default cases
to these switches ensure that if we do get in an unexpected situation,
it is caught. In GDB, I'd use gdb_assert_not_reached, I don't know if
there is something similar in sim so I went with abort.
sim/common/ChangeLog:
* sim-options.c (standard_option_handler): Add default cases to
switches.
Mike Frysinger [Sun, 2 May 2021 04:07:21 +0000 (00:07 -0400)]
sim: replace custom attributes with ansidecl.h
A lot of this code predates the common attributes. We had already
started migrating over piece by piece, so just do a pass across all
the attributes and replace most of them.
Mike Frysinger [Sat, 2 Jan 2016 15:54:42 +0000 (10:54 -0500)]
sim: bfin: move option inits to respective modules
Now that modules can self declare their own init funcs, change the mmu
and mach logic to use it. We don't need to export the option symbols
or specifically call this logic from the sim_open function anymore.
Mike Frysinger [Sun, 2 May 2021 03:04:01 +0000 (23:04 -0400)]
sim: options: fix --help output
The hash table rewrite broke --help output due to subtle behavior:
calling dup_arg_p(NULL) will create & clear the table, not just
create it. The --help output relies on this to clear the table
before it shows things.
Mike Frysinger [Sat, 2 Jan 2016 15:50:46 +0000 (10:50 -0500)]
sim: add framework for declaring init callbacks locally
To facilitate decentralized module initialization/registration with an
eye towards multi-target support, add a framework to detect init calls
declared in the source and automatically call them. This is akin to
gdb's _initialize_xxx framework for letting modules autodiscover.
Mike Frysinger [Sat, 1 May 2021 20:30:59 +0000 (16:30 -0400)]
sim: nrun: add local strsignal prototype
While libiberty provides a definition for this for systems that lack
the function (e.g. Windows), it doesn't provide a prototype. So add
our own local copy in the one file that uses the func.
Mike Frysinger [Sat, 24 Apr 2021 18:28:17 +0000 (14:28 -0400)]
sim: callback: inline wrap helper
This is annoying as it requires inlining boiler plate, but we don't
have much choice: the wrap helper assumes the return value is always
an int, but that's already not the case with some of the callbacks
which use long. GCC has extensions to define macros-as-functions,
but we can't assume GCC.
Tom Tromey [Fri, 30 Apr 2021 20:07:58 +0000 (14:07 -0600)]
Do not separately read type units
Currently, the DWARF reader has a separate pass to read type units --
create_all_type_units. While working on other patches, I discovered
that this caused DWARF 5 type units to be read twice, once by
create_all_comp_units and once by create_all_type_units.
There's no need any more (if there ever was) to treat type units
differently from CUs. So, this patch removes create_all_type_units
and unifies the code paths.
Note that the DWO code still has a second pass. I haven't looked into
this code yet; perhaps it can also be simplified.
Regression tested using the debug-types board file on x86-64 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 30 Apr 2021 20:07:58 +0000 (14:07 -0600)]
Remove dwarf2_per_bfd::all_type_units
I don't think there is any deep reason to separate CUs and TUs in
dwarf2_per_bfd. This patch removes all_type_units and unifies these
two containers. Some minor tweaks are needed to the index writers,
because both forms of index keep CUs and TUs separate;
Regression tested on x86-63 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 30 Apr 2021 20:07:58 +0000 (14:07 -0600)]
Allocate dwarf2_per_cu_data with 'new'
In a patch series I am working on, I'd like to have a non-POD member
in dwarf2_per_cu_data. This currently can't be done because
dwarf2_per_cu_data is allocated on an obstack and initialized with
memset.
This patch changes the DWARF reader to allocate objects of this type
with 'new'. The various "subclasses" of this type (signatured_type in
particular) are now changed to derive from dwarf2_per_cu_data, and
also use 'new' for allocation.
Regression tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 30 Apr 2021 16:22:23 +0000 (10:22 -0600)]
Share DLL code between gdb and gdbserver
This moves the new DLL-loading code into nat/windows-nat.c, and
changes both gdb and gdbserver to use the shared code. One
client-provided callback, handle_load_dll, is changed to allow the
code to be shared. This callback was actually never called from
nat/windows-nat.c; maybe I had planned to share more here and then
didn't finish... I'm not sure.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_load_dll): Update.
(windows_nat_target::get_windows_debug_event): Call
dll_loaded_event.
(windows_add_all_dlls, windows_add_dll): Move to
nat/windows-nat.c.
* nat/windows-nat.h (handle_load_dll): Change parameters.
(dll_loaded_event, windows_add_all_dlls): Declare.
* nat/windows-nat.c (windows_add_dll, windows_add_all_dlls): Move
from windows-nat.c.
(dll_loaded_event): New function.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
Tom Tromey [Fri, 30 Apr 2021 16:22:23 +0000 (10:22 -0600)]
Use nat/windows-nat function indirection code
This changes gdbserver to use the function indirection code that was
just moved into nat/windows-nat.[ch]. One additional function is used
by gdbserver that was not used by gdb.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
Tom Tromey [Fri, 30 Apr 2021 16:22:23 +0000 (10:22 -0600)]
Move function indirection code to nat/windows-nat
gdb and gdbserver both look for functions in some Windows DLLs at
runtime. This patch moves this code out of gdb and into
nat/windows-nat, so it can be shared by both programs.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
Tom Tromey [Fri, 30 Apr 2021 16:04:56 +0000 (10:04 -0600)]
Use rvalue reference in thread_pool::post_task
Tankut's recent patches made me realize that thread_pool::post_task
should have used an rvalue reference for its parameter. This patch
makes this change.
gdbsupport/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* thread-pool.cc (thread_pool::post_task): Update.
* thread-pool.h (class thread_pool) <post_task>: Take rvalue
reference to function.
Tom Tromey [Thu, 15 Apr 2021 14:54:06 +0000 (08:54 -0600)]
Fix crash with GNAT minimal encodings
Running the AdaCore internal test suite with -fgnat-encodings=minimal
found a gdb crash. The bug is that GDB ends up with a typedef in
ada_index_type, resulting in a NULL dereference.
This crash can be reproduced using GCC 11 with the included test case.
Tested on x86-64 Fedora 32. Because this is Ada-specific, and was
already reviewed by Joel, I am going to check it in.
2021-04-30 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_index_type): Use ada_check_typedef.
gdb/testsuite/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* gdb.ada/enum_idx_packed/pck.ads (My_Enum, My_Array_Type)
(Confused_Array): New types.
* gdb.ada/enum_idx_packed/foo.adb (Confused_Array): New variable.
* gdb.ada/enum_idx_packed.exp: Add new tests.
projects / thirdparty / binutils-gdb.git / log
