This patch removes a call to erase_data_content in refresh_all and
then removes some other calls that are more clearly unnecessary once
one follows calls from that point.
gdb/ChangeLog
2019-08-30 Tom Tromey <tom@tromey.com>
* tui/tui-regs.c (tui_data_window::display_registers_from_line)
(tui_data_window::rerender): Don't call
check_and_display_highlight_if_needed.
(tui_data_window::refresh_all): Remove call to
erase_data_content.
A few methods in tui_data_window check whether the contents are empty;
but all the callers already check this, so these calls can be removed.
gdb/ChangeLog
2019-08-30 Tom Tromey <tom@tromey.com>
* tui/tui-regs.c (tui_data_window::last_regs_line_no)
(tui_data_window::display_registers_from)
(tui_data_window::display_reg_element_at_line)
(tui_data_window::display_registers_from_line): Remove checks of
"empty".
tui_data_window::rerender clears the data item windows, and then calls
display_all_data. However, that method only does anything if the
contents are not empty. So, display_all_data can be renamed and the
wrapper removed.
gdb/ChangeLog
2019-08-30 Tom Tromey <tom@tromey.com>
* tui/tui-regs.h (struct tui_data_window) <display_all_data>:
Don't declare.
* tui/tui-regs.c (tui_data_window::show_registers): Call
rerender.
(tui_data_window::rerender): Rename from display_all_data.
(tui_data_window::rerender): Remove old implementation.
NO_DATA_STRING shouldn't be used. It's referenced in a single spot,
in tui_data_window::display_all_data. This patch removes the use and
replaces it with the more correct text. A later patch (though not in
this series) will remove this call entirely, when it's more obviously
correct to do so.
gdb/ChangeLog
2019-08-30 Tom Tromey <tom@tromey.com>
* tui/tui-regs.c (tui_data_window::display_all_data): Change
text.
* tui/tui-data.h (NO_DATA_STRING): Remove define.
We need to copy BFD_COMPRESS, BFD_DECOMPRESS and BFD_COMPRESS_GABI flags
for thin archive.
PR ld/24951
* archive.c (_bfd_get_elt_at_filepos): Copy BFD_COMPRESS,
BFD_DECOMPRESS and BFD_COMPRESS_GABI flags for thin archive.
This patch make changes to the assembler to encode MVE VMOV instruction "a" same as "b".
a: VMOV<c><q> <Dd>, <Dm>
b: VMOV<c><q>.F64 <Dd>, <Dm>
gas/ChangeLog:
2019-08-30 Srinath Parvathaneni <srinath.parvathaneni@arm.com>
* config/tc-arm.c (do_neon_mov): Modify "if" statement.
* testsuite/gas/arm/mve-vmov-bad-3.d: New test.
* testsuite/gas/arm/mve-vmov-bad-3.l: Likewise.
* testsuite/gas/arm/mve-vmov-bad-3.s: Likewise.
Move FASTMATH to the right enum.
2019-08-30 Claudiu Zissulescu <claziss@gmail.com>
* opcode/arc.h (FASTMATH): Move it from insn_class_t to
insn_subclass_t enum.
This testcase was originally for PR gdb/15415, a problem with the
"run" command expanding symlinks in the name of the program being run.
It does not correctly distinguish between files on build, host, and
target, and it is not clear if it would be testing anything useful in
configurations where "run" is not being used.
2019-08-29 Sandra Loosemore <sandra@codesourcery.com>
* gdb.base/argv0-symlink.exp: Run only on native target
and local host.
This was reported by Bernhard Wodok, along with a patch to fix the
issue. I adjusted the patch a bit, and I'm submitting the patch on
his behalf.
According to Bernhard, the issue can be reproduced by doing:
1. start gdb
2. enter 'target remote :2345'
3. observe that it throws a "connection refused" error immediately
instead of waiting and throwing a timeout error
I.e., I believe it can be reproduced by our current tests, which is
why I'm not proposing any extra tests here (well, I don't use nor have
any Windows system to test this, so...).
The problem happens because, on ser-tcp:wait_for_connect, we call
'gdb_select' passing 0 as its first argument, which, when using MinGW,
ends up using the 'gdb_select' version from mingw-hdep.c, and when the
first argument is 0 this means that WaitForMultipleObjects will be
called with 0 as its first argument as well. According to the MS API
docs, this is forbidden:
https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects
The proposed fix is simple: we just call Sleep when N == 0 (and when
TIMEOUT is non-NULL), and return 0. It makes sense to me.
Both Bernhard and Paul Carroll confirmed that the fix works. I'm
Cc'ing Bernhard in case you have any questions about the patch.
OK?
gdb/ChangeLog:
2019-08-29 Bernhard Wodok <barto@gmx.net>
Sergio Durigan Junior <sergiodj@redhat.com>
PR win32/24284
* mingw-hdep.c (gdb_select): Handle case when 'n' is zero.
The gdb.fortran/info-types.exp test-case passes with gcc 7 (though not on
openSUSE, due to the extra debug info) and fails with gcc 4.8 and gcc 8.
Fix the gdb_test regexp to fix all those cases.
gdb/testsuite/ChangeLog:
2019-08-29 Tom de Vries <tdevries@suse.de>
* gdb.fortran/info-types.exp: Fix gdb_test regexp to allow more
diverse debug info.
* lib/fortran.exp (fortran_int8): New proc, based on fortran_int4.
This removes a restriction on various R_PPC_EMB relocations that has
been present for ppc32 since 1996-04-26 git commit e25a798839. As far
as I know, only those relocs that would require addressing via r2 for
.sdata2/.sbss2 access are disallowed in shared libraries.
PR 24697
* elf32-ppc.c (ppc_elf_check_relocs): Call bad_shared_reloc
when !bfd_link_executable for R_PPC_EMB_SDA2I16 and
R_PPC_EMB_SDA2REL. Don't call bad_shared_reloc for any other
reloc.
We can easily support an offset on the second instruction of a
sequence marked with R_PPC64_PCREL_OPT. For example,
pla ra,symbol@pcrel
ld rt,off(ra)
can be optimised to
pld rt,symbol+off@pcrel
nop
* elf64-ppc.c (xlate_pcrel_opt): Add poff parameter. Allow offset
on second insn, return it in poff.
(ppc64_elf_relocate_section): Add offset to paddi addend for
PCREL_OPT.
This was broken when I changed how we compute the value for the gp register.
It used to be computed inside the sdata section. Now it is computed at the
end which makes it an abs section symbol. There is code that tries to use
the alignment of the section that the gp value is in, but this does not work
if it is in the abs section, as the abs section has alignment of 1 byte.
There are people using alternative linker scripts that still define it in the
sdata section, so the code is still useful. Thus adding a check to disable
this when gp is in the abs section.
bfd/
* elfnn-riscv.c (_bfd_riscv_relax_lui): Add check to exclude abs
section when setting max_alignment. Update comment.
(_bfd_riscv_relax_pc): Likewise.
I don't see a need to calculate "ptr = start + uvalue" then compare
"ptr" with "start" and "end". Given "start <= end" on entry, the
"uvalue" comparison with "max_uvalue" ought to be sufficient to ensure
"start + uvalue" is bounded by "start" and "end" regardless of the
size of pointers and the unsigned dwarf_vma integer type.
* dwarf.c (check_uvalue): Remove unnecessary pointer checks.
BFD was leaking memory in bfd_check_format_matches. As part of
deciding the proper format of an archive, BFD looks at the format of
the first file stored. That file's bfd was left open for reasons
given in a comment removed in git commit 0e71e4955c that said:
/* We ought to close `first' here, but we can't, because
we have no way to remove it from the archive cache.
It's close to impossible to figure out when we can
release bfd_ardata. FIXME. */
Well, things have changed since that comment was true and we now can
remove files from the archive cache. Closing the first file is good
and cures some of the leaks. Other leaks are caused by
bfd_check_format_matches throwing away bfd tdata before trying a new
match. That lost the element cache set up when format checking the
first element in the archive. The easiest and cleanest fix is to
simply disable the caching when checking the first element.
PR 24891
* bfd.c (struct bfd): Add no_element_cache.
* archive.c (_bfd_get_elt_at_filepos): Don't add element to
archive cache when no_element_cache.
(bfd_generic_archive_p): Set no_element_cache when opening first
element to check format. Close first element too.
(do_slurp_bsd_armap): Don't zero ardata->cache here.
* bfd-in2.h: Regenerate.
On openSUSE Leap 15.1, I get:
...
FAIL: gdb.base/info-var.exp: info variables
FAIL: gdb.base/info-var.exp: info variables -n
...
because the info variables command prints info also for init.c:
...
File init.c:^M
24: const int _IO_stdin_used;^M
...
while the regexps in the test-case only expect info for info-var-f1.c and
info-var-f2.c.
Fix this by extending the regexps.
Tested on x86_64-linux, both openSUSE Leap 15.1 and Fedora 30.
gdb/testsuite/ChangeLog:
2019-08-28 Tom de Vries <tdevries@suse.de>
* gdb.base/info-var.exp: Allow info variables to print info for files
other than info-var-f1.c and info-var-f2.c.
Caused by the PR24406 fix. unwrap_hash_lookup shouldn't be called
with link_info.wrap_hash NULL.
PR ld/24406
* plugin.c (get_symbols): Test link_info.wrap_hash before calling
unwrap_hash_lookup.
Coverity discovered a number of resource leaks in Gnulib's glob.c.
This commit backports the Gnulib commits that fix the leaks.
gnulib/ChangeLog:
* patches/0003-Fix-glob-c-Coverity-issues.patch: New file.
* update-gnulib.sh: List the above.
* import/glob.c: Rebuild.
Currently the 'info types' command will return symbols that correspond
to Fortran modules. This is because the symbols are created with
domain MODULE_DOMAIN and address_class LOC_TYPEDEF. The address_class
LOC_TYPEDEF is the same address_class used for type symbols which is
why the modules show up when listing types.
This commit explicitly prevents symbols in the MODULE_DOMAIN from
appearing when we search for symbols in the TYPES_DOMAIN, this
prevents the Fortran module symbols from appearing in the output of
'info types'.
gdb/ChangeLog:
* symtab.c (search_symbols): Don't include MODULE_DOMAIN symbols
when searching for types.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-types.exp: Add module.
* gdb.fortran/info-types.f90: Update expected results.
Implement an la_print_typedef method for Fortran, this allows 'info
types' to work for Fortran. The implementation is just copied from
ada_print_typedef (with the appropriate changes).
To support the testing of this patch I added a new proc,
fortran_character1, to lib/fortran.exp which returns a regexp to match
a 1-byte character type. The regexp returned is correct for current
versions of gFortran. All of the other regexp are guesses based on
all of the other support procs in lib/fortran.exp, I haven't tested
them myself.
gdb/ChangeLog:
* f-lang.c (f_language_defn): Use f_print_typedef.
* f-lang.h (f_print_typedef): Declare.
* f-typeprint.c (f_print_typedef): Define.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-types.exp: New file.
* gdb.fortran/info-types.f90: New file.
* lib/fortran.exp (fortran_character1): New proc.
PR 24931
* objdump.c (source_comment): New static variable.
(option_values): Add OPTION_SOURCE_COMMENT.
(long_opions): Add --source-comment.
(print_line): If source comment is set, use it as a prefix to the
source code line.
(main): Handle OPTION_SOURCE_COMMENT.
* doc/binutils.texi: Document the new option.
* NEWS: Mention the new feature.
* testsuite/binutils-all/objdump.exp (test_objdump_S): Add tests
of the -S and --source-comment options.
../../gdb/nat/linux-namespaces.c: In function ‘void mnsh_main(int)’:
../../gdb/nat/linux-namespaces.c:604:8: warning: ‘fd’ may be used uninitialized in this function [-Wmaybe-uninitialized]
close (fd);
~~~~~~^~~~
And the warning is correct -- mnsh_recv_message can return -1 and leave fd
uninitialized, and mnsh_main will still call close (fd) if that happens.
Initialize fd to -1 to avoid that.
gdb/ChangeLog:
2019-08-27 Christian Biesinger <cbiesinger@google.com>
* nat/linux-namespaces.c (mnsh_main): Initialize fd (to -1).
The 'info variables', its alias 'whereis', and 'info functions' all
include non-debug symbols in the output by default. The list of
non-debug symbols can sometimes be quite long, resulting in the
debug symbol based results being scrolled off the screen.
This commit adds a '-n' flag to all of the commands listed above that
excludes the non-debug symbols from the results, leaving just the
debug symbol based results.
gdb/ChangeLog:
* cli/cli-utils.c (info_print_options_defs): Delete.
(make_info_print_options_def_group): Delete.
(extract_info_print_options): Delete.
(info_print_command_completer): Delete.
(info_print_args_help): Add extra parameter, and optionally
include text about -n flag.
* cli/cli-utils.h (struct info_print_options): Delete.
(extract_info_print_options): Delete declaration.
(info_print_command_completer): Delete declaration.
(info_print_args_help): Add extra parameter, extend header
comment.
* python/python.c (gdbpy_rbreak): Pass additional parameter to
search_symbols.
* stack.c (struct info_print_options): New type.
(info_print_options_defs): New file scoped variable.
(make_info_print_options_def_group): New static function.
(info_print_command_completer): New static function.
(info_locals_command): Update to use new local functions.
(info_args_command): Likewise.
(_initialize_stack): Add extra parameter to calls to
info_print_args_help.
* symtab.c (search_symbols): Add extra parameter, use this to
possibly excluse non-debug symbols.
(symtab_symbol_info): Add extra parameter, which is passed on to
search_symbols.
(struct info_print_options): New type.
(info_print_options_defs): New file scoped variable.
(make_info_print_options_def_group): New static function.
(info_print_command_completer): New static function.
(info_variables_command): Update to use local functions, and pass
extra parameter through to symtab_symbol_info.
(info_functions_command): Likewise.
(info_types_command): Pass additional argument through to
symtab_symbol_info.
(rbreak_command): Pass extra argument to search_symbols.
(_initialize_symtab): Add extra arguments for calls to
info_print_args_help, and update help text for 'info variables',
'whereis', and 'info functions' commands.
* symtab.h (search_symbols): Add extra argument to declaration.
* NEWS: Mention new flags.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Add information about the -n flag to
"info variables" and "info functions".
gdb/testsuite/ChangeLog:
* gdb.base/info-fun.exp: Extend to test the -n flag for 'info
functions'. Reindent as needed.
* gdb.base/info-var-f1.c: New file.
* gdb.base/info-var-f2.c: New file.
* gdb.base/info-var.exp: New file.
* gdb.base/info-var.h: New file.
gas * config/tc-arm.c (parse_neon_mov): Add check to accept vector
register to both the arguments in VMOV instruction.
* testsuite/gas/arm/mve-vmov-1.d: Modify.
* testsuite/gas/arm/mve-vmov-1.s: Likewise.
* testsuite/gas/arm/mve-vorr.d: Likewise.
opcodes * arm-dis.c (mve_opcodes): Add entry for MVE_VMOV_VEC_TO_VEC.
(is_mve_undefined): Add case for MVE_VMOV_VEC_TO_VEC.
(print_insn_mve): Add condition to check Qm==Qn of VORR instruction.
The two functions are extremely similar; this factors out their code into
a shared _internal function.
gdb/ChangeLog:
2019-08-26 Christian Biesinger <cbiesinger@google.com>
* symtab.c (lookup_static_symbol): Call the new function (and move
it down to be next to lookup_global_symbol).
(struct global_sym_lookup_data): Add block_enum member and rename to...
(struct global_or_static_sym_lookup_data): ...this.
(lookup_symbol_global_iterator_cb): Pass block_index instead of
GLOBAL_BLOCK to lookup_symbol_in_objfile and rename to...
(lookup_symbol_global_or_static_iterator_cb): ...this.
(lookup_global_or_static_symbol): New function.
(lookup_global_symbol): Call new function.
When using catch catch/rethrow/catch, a libstdcxx with SDT probes is required
for both the regexp argument, and the convenience variable $_exception (
https://sourceware.org/gdb/current/onlinedocs/gdb/Set-Catchpoints.html ).
Currently, when using these features with a libstdcxx without SDT probes, we
get the cryptic error message:
...
not stopped at a C++ exception catchpoint
...
Improve this by instead emitting the more helpful:
...
did not find exception probe (does libstdcxx have SDT probes?)
...
Tested on x86_64-linux.
gdb/ChangeLog:
2019-08-26 Tom de Vries <tdevries@suse.de>
PR c++/24852
* break-catch-throw.c (fetch_probe_arguments): Improve error mesage
when pc_probe.prob == NULL.
gdb/testsuite/ChangeLog:
2019-08-26 Tom de Vries <tdevries@suse.de>
PR c++/24852
* gdb.cp/no-libstdcxx-probe.exp: New test.
The tcl proc skip_libstdcxx_probe_tests currently returns 0 if the probe tests
need to be skipped, while tcl interprets 0 as false rather than true, which is
confusing.
Fix this by making skip_libstdcxx_probe_tests return 1 if the probe tests need
to be skipped.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-26 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (skip_libstdcxx_probe_tests_prompt): Return 1 if probe
* tests need to be skipped.
* gdb.cp/exceptprint.exp: Update call to skip_libstdcxx_probe_tests.
* gdb.mi/mi-catch-cpp-exceptions.exp: Update call to
mi_skip_libstdcxx_probe_tests.
The way unrecognized escape sequences are handled has changed in
Python 3.8: users now see a SyntaxWarning message, which will
eventually become a SyntaxError in future versions of Python:
(gdb) source /blabla/gdb.python/py-xmethods/py-xmethods.py
/blabla/gdb.python/py-xmethods/py-xmethods.py:204: SyntaxWarning: invalid escape seque
nce \+
'operator\+',
/blabla/gdb.python/py-xmethods/py-xmethods.py:211: SyntaxWarning: invalid escape seque
nce \+
'operator\+\+',
One of our testcases, gdb.python/py-xmethods.exp, contains strings in
the form of "operator\+". This is not recognized by Python, but is
still needed by the testsuite to work properly. The solution is
simple: we just have to make sure these strings are marked as
raw (i.e, r""). This is what this patch does. I took the opportunity
to also convert other strings to raw, which, in two cases, allowed the
removal of an extra backslash.
I tested this using Python 3.7 and Python 3.8, and everything works
fine.
I think I could push this as obvious, but decided to send it to
gdb-patches just in case.
gdb/testsuite/ChangeLog:
2019-08-26 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.python/py-xmethods.exp: Use raw strings when passing
arguments to SimpleXMethodMatcher.
li is a pseudo instruction in RISC-V, it might expand to more than one
instructions if the immediate value can't fit addi or lui, but the
assembler will always using 4-byte instructions during expansion.
For example:
li a0, 0x12345001
will expand into
12345537 lui a0,0x12345
00150513 addi a0,a0,1
but addi could be compress into
0505 addi a0,a0,1
It because load_const use macro_build to emit instructions,
and macro_build call append_insn, and expect it will compress
it if possible, but the fact is append_insn never compress anything,
So this patch redirect the li expansion flow to normal instruction
emission flow via md_assemble, added md_assemblef as an wrapper for
that for easier emit instruction with printf-style argument to build
instruction.
gas/ChangeLog:
* tc-riscv.c (md_assemblef): New.
(load_const) Use md_assemblef instead of macro_build to emit
instructions.
* testsuite/gas/riscv/li32.d: New.
* testsuite/gas/riscv/li32.s: Ditto.
* testsuite/gas/riscv/li64.d: Ditto.
* testsuite/gas/riscv/li64.s: Ditto.
gcc 4.8 (and probably other versions too) doesn't like that the local
variable symbol_linkage has the same name as the enum class defined in
the same context:
CXX dwarf2read.o
/home/smarchi/src/binutils-gdb/gdb/dwarf2read.c: In member function ‘dwarf2_per_cu_data* dw2_debug_names_iterator::next()’:
/home/smarchi/src/binutils-gdb/gdb/dwarf2read.c:5850:22: error: ‘symbol_linkage’ is not a class, namespace, or enumeration
} symbol_linkage = symbol_linkage::unknown;
^
Rename the local variable to avoid this.
This problem was originally reported with the Netbsd builder on the
buildbot, which uses gcc 5.5, I believe. I am not able to test it on
that builder right now, but chances are that the fix will work there
too.
gdb/ChangeLog:
* dwarf2read.c (dw2_debug_names_iterator::next): Rename local
variable symbol_linkage to symbol_linkage_.
gdb::optional<bool> is dangerous, because it's easy to do:
if (opt_bool)
when you actually meant
if (*opt_bool)
or vice-versa. The first checks if the optional is set, the second
checks if the wrapped bool is true.
Replace it with an enum that explicitly defines the three possible
states.
gdb/ChangeLog:
* dwarf2read.c (dw2_debug_names_iterator::next): Use enum to
represent whether the symbol is static, dynamic, or we don't
know.
My compiler (g++ 8.2) can't tell that *bsc_ptr and *slot_ptr are
only used in the cases when it does get initialized. Just initialize
the vars earlier to avoid the warning, there does not seem to be a
downside to it.
../../gdb/symtab.c: In function ‘block_symbol lookup_static_symbol(const char*, domain_enum)’:
../../gdb/symtab.c:1366:11: warning: ‘slot’ may be used uninitialized in this function [-Wmaybe-uninitialized]
xfree (slot->value.not_found.name);
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/symtab.c:2578:29: note: ‘slot’ was declared here
struct symbol_cache_slot *slot;
^~~~
../../gdb/symtab.c:1405:3: warning: ‘bsc’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (bsc == NULL)
^~
../../gdb/symtab.c:2577:30: note: ‘bsc’ was declared here
struct block_symbol_cache *bsc;
^~~
../../gdb/symtab.c: In function ‘block_symbol lookup_global_symbol(const char*, const block*, domain_enum)’:
../../gdb/symtab.c:1366:11: warning: ‘slot’ may be used uninitialized in this function [-Wmaybe-uninitialized]
xfree (slot->value.not_found.name);
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/symtab.c:2658:29: note: ‘slot’ was declared here
struct symbol_cache_slot *slot;
^~~~
../../gdb/symtab.c:1409:14: warning: ‘bsc’ may be used uninitialized in this function [-Wmaybe-uninitialized]
++bsc->collisions;
~~~~~^~~~~~~~~~
../../gdb/symtab.c:2657:30: note: ‘bsc’ was declared here
struct block_symbol_cache *bsc;
^~~
gdb/ChangeLog:
2019-08-22 Christian Biesinger <cbiesinger@google.com>
* symtab.c (symbol_cache_lookup): Always initialize *bsc_ptr and *slot_ptr.
Found on a GOT reference to __ehdr_start, which is tweaked to be
undefined weak at some stages of linking. SYMBOL_REFERENCES_LOCAL
isn't a sufficient test.
* elf64-ppc.c (ppc64_elf_edit_toc): Exclude undefined weak
symbols from GOT optimisation.
I need to use 'gdb_dlopen' inside 'gdbsupport/', but it's not yet
supported there. This commit moves 'gdb-dlfcn.[ch]' to 'gdbsupport/',
which makes it available also on gdbserver.
gdb/ChangeLog:
2019-08-23 Sergio Durigan Junior <sergiodj@redhat.com>
* configure.ac: Don't check for 'dlfcn.h' (moved to
gdbsupport/common.m4).
* Makefile.in (COMMON_SFILES): Move 'gdb-dlfcn.c' to
'gdbsupport/'.
(HFILES_NO_SRCDIR): Likewise, for 'gdb-dlfcn.h'.
* compile/compile-c-support.c: Include
'gdbsupport/gdb-dlfcn.h'.
* gdbsupport/common.m4: Check for 'dlfcn.h'.
* gdb-dlfcn.c: Move to...
* gdbsupport/gdb-dlfcn.c: ... here.
* gdb-dlfcn.h: Move to...
* gdbsupport/gdb-dlfcn.h: ... here.
gdb/gdbserver/ChangeLog:
2019-08-23 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (SFILES): Add 'gdbsupport/gdb-dlfcn.c'.
(OBS): Add 'gdbsupport/gdb-dlfcn.o'.
* config.in: Regenerate.
* configure: Regenerate.
The nios2 prologue analyzer was mistakenly using an unsigned int field
to represent a 32-bit signed value. This caused problems with an
incorrect conversion being applied to negative values when they were
automatically promoted for addition to a 64-bit CORE_ADDR value.
This patch fixes test failures in gdb.base/large-frame.exp and
gdb.dwarf2/dw2-ref-missing-frame.exp. Normally the nios2 backend
prefers to use the dwarf2 unwinder so the prologue analyzer is only
invoked if there is no dwarf2 information.
2019-08-23 Sandra Loosemore <sandra@codesourcery.com>
gdb/
* nios2-tdep.c (struct reg_value): Improve comments. Make
the offset field signed.
The PLT GOT entry should point to the first PLT entry which contains the
runtime linker function. It was pointing back to the symbol PLT entry
causing an infinite loop.
I found this when testing the OpenRISC glibc port which uses the runtime
dynamic linker. It seems other libc's we use so far have not been
making use of the initial PLT GOT entries.
bfd/ChangeLog:
* elf32-or1k.c (or1k_elf_finish_dynamic_symbol): Use correct value for
PLT GOT entries.
PR 24456
* elf.c (bfd_section_from_shdr): Issue an informative warning
message and continue processing other sections after encountering
a reloc section for a section which already has other relocs
associated with it.