When debugging Ada programs compiled by certain versions of GNAT with
-fgnat-encodings=minimal, gdb can crash. These crashes occur when
running the gdb test suite, once some of the later patches in this
series have been applied.
This patch works around the bug by throwing an exception in the
failing case. I did not implement a full fix because GNAT has been
changed to emit better DWARF, and so in the near future this will stop
being a problem. (Currently, users don't generally use
-fgnat-encodings=minimal, and the GNAT default will only be changed in
a fully-patched compiler.)
gdb/ChangeLog
2020-11-04 Tom Tromey <tromey@adacore.com>
* ada-lang.c (to_fixed_array_type): Error if
decode_constrained_packed_array_type returns NULL.
read_3_bytes assumes little-endian data, but in fact it depends on the
BFD. This patch rewrites this function to use bfd_get_24 instead.
2020-11-04 Tom Tromey <tromey@adacore.com>
* dwarf2/leb.h (read_3_bytes): Use bfd_get_24.
The abbreviations table for a single compilation unit has two types of
terminators:
- a ".byte 0" pair denoting the end of an attribute list
- a single ".byte 0" denoting the end of the table
However, at the end of the .debug_abbrev section in dw2-line-number-zero-dw.S,
we have four ".byte 0" entries:
...
.uleb128 0x12 /* DW_AT_high_pc */
.uleb128 0x01 /* DW_FORM_addr */
.byte 0x0 /* Terminator */
.byte 0x0 /* Terminator */
.byte 0x0 /* Terminator */
.byte 0x0 /* Terminator */
...
The first two are the attribute list terminator, the third is the end-of-table
terminator, and the last is superfluous/incorrect.
Fix this by emitting instead:
...
.uleb128 0x12 /* DW_AT_high_pc */
.uleb128 0x01 /* DW_FORM_addr */
.byte 0x0 /* DW_AT - Terminator */
.byte 0x0 /* DW_FORM - Terminator */
.byte 0x0 /* Abbrev end - Terminator */
...
where the last comment resembles the comment for other abbreviation codes:
...
.section .debug_abbrev
.Labbrev1_begin:
.uleb128 2 /* Abbrev start */
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-11-03 Tom de Vries <tdevries@suse.de>
* lib/dwarf.exp (Dwarf::_handle_DW_TAG): Improve attribute list
terminator comments.
(Dwarf::cu, Dwarf::tu): Remove superfluous abbreviation table
terminator.
* ar.c (long_options): Add --record-libdeps.
(usage): Mention the new option.
(decode_options): Handle the new option.
(replace_members): If necessary, create a bfd to hold the libdeps
description.
* binemul.c (ar_emul_append_bfd): New function.
(ar_emul_replace_bfd): New function.
(ar_emul_default_append): Replace file_name and target arguments
with new_bfd argument.
(ar_emul_default_replace): Likewise.
* binemul.h: Update prototypes.
(struct bin_emulation_xfer_struct): Update fields.
* doc/binutils.texi: Document the new option.
* NEWS: Mention the new feature.
* emul_aix.c (ar_emul_aix_append): Update.
(ar_emul_aix_replace): Likewise.
* testsuite/binutils-all/ar.exp: Add test of new feature.
Armv8.7 architecture introduces the "accelerator extension", aka
load/store of 64 bytes. New atomic load/store instructions are: LD64B,
ST64B, ST64BV and ST64BV0.
This patch adds:
+ New feature +ls64 to -march command line.
+ New atomic load/store instructions associated with above feature.
For more details regarding atomic 64-byte load/store instruction for
Armv8.7 please refer to Arm A64 Instruction set documentation for
Armv8-A architecture profile, see document page 157 for load
instruction, and pages 414-418 for store instructions of [0].
[0]: https://developer.arm.com/docs/ddi0596/i
Symbol value is in bytes while fragS::fr_address is in octets. Fixes GAS
symver12 and symver13 tests on ELF targets with with OCTETS_PER_BYTE>1.
* config/obj-elf (elf_frob_symbol): Fix symbol value calculation
for versioned symbol aliases.
Signed-off-by: Christian Eggers <ceggers@gmx.de>
Since upgrading to binutils 2.35 I've been experiencing random memory
corruption related crashes with ld.gold --threads. It's caused by
multiple threads concurrently pushing elements onto the shared
std::vector in File_read::record_file_read(). This vector is supposed to
be protected by file_counts_lock, but that is initialized lazily and
might be NULL when File_read::open() is called, in which case
Hold_optional_lock silently skips locking it.
Fix by calling the initialize() method before attempting to acquire the
lock, the same as other places that use file_counts_lock.
PR 26827
* fileread.cc (File_read::open): Ensure file_counts_lock is
initialized.
* testsuite/Makefile.am (check_PROGRAMS): Add a test that passes
-Wl,--threads.
* testsuite/Makefile.in: Regenerate.
This test fails on my machine:
p /x $pc^M
$2 = 0x55555555514e^M
(gdb) PASS: gdb.base/step-over-no-symbols.exp: displaced=off: get after PC
FAIL: gdb.base/step-over-no-symbols.exp: displaced=off: advanced
This is due to the check added in 5f0e2eb79e ("GDB/testsuite: Fix a
catastrophic step-over-no-symbols.exp failure"), that makes sure the PC
values are integer. As documented in the TCL doc [1], "string is
integer" returns 1 if the string is a valid 32-bit integer format. The
PC values are greater than 32 bits, so are not recognized as integers by
that test.
% string is integer -strict 0x55555555
1
% string is integer -strict 0x555555555
0
Replace the "string is integer" test with a regexp one, that verifies
the PC is a hex value.
[1] https://www.tcl.tk/man/tcl/TclCmd/string.htm#M21
gdb/testsuite/ChangeLog:
* gdb.base/step-over-no-symbols.exp (test_step_over): Replace
integer format test with regexp.
Change-Id: I71f8197e7b52e97b4901980544a8d1072aabd362
Support for x86_64 ravenscar was recently added to the Ada runtime.
This patch updates gdb to follow.
As this is Ada-specific, and was reviewed internally by Joel, I am
checking it in.
2020-11-02 Tom Tromey <tromey@adacore.com>
* Makefile.in (ALL_64_TARGET_OBS): Add amd64-ravenscar-thread.o.
(ALLDEPFILES): Add amd64-ravenscar-thread.c.
(HFILES_NO_SRCDIR): Add amd64-ravenscar-thread.h.
* amd64-ravenscar-thread.c: New file.
* amd64-ravenscar-thread.h: New file.
* amd64-tdep.c (amd64_init_abi): Register ravenscar ops.
* configure.tgt (amd64_tobjs): Add ravenscar objects.
Small refactor to wrap up executing the scripts and commands passed
using the -x, -ex, -ix, -iex command line flags.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* main.c (execute_cmdargs): New function.
(captured_main_1): Make use of execute_cmdargs.
This commit effectively changes the default location of the .gdbinit
file, while maintaining backward compatibility.
For non Apple hosts the .gdbinit file will now be looked for in the
following locations:
$XDG_CONFIG_HOME/gdb/gdbinit
$HOME/.config/gdb/gdbinit
$HOME/.gdbinit
On Apple hosts the search order is instead:
$HOME/Library/Preferences/gdb/gdbinit
$HOME/.gdbinit
I've performed an extensive rewrite of the documentation, moving all
information about initialization files and where to find them into a
new @node, text from other areas has been moved into this one
location, and other areas cross-reference to this new @node as much as
possible.
gdb/ChangeLog:
* NEWS: Mention changes to config file search path.
* main.c
gdb/doc/ChangeLog:
* gdb.texinfo (Mode Options): Descriptions of initialization files
has been moved to 'Initialization Files'.
(Startup): Likewise.
(Initialization Files): New node.
(gdb man): Update to mention alternative file paths.
(gdbinit man): Likewise.
This adds a new get_standard_config_dir, which returns the name of the
configuration directory. In XDG, this is ~/.config/gdb/. Future
patches will make use of this.
2020-07-05 Tom Tromey <tom@tromey.com>
* pathstuff.h (get_standard_config_dir): Declare.
* pathstuff.cc (get_standard_config_dir): New function.
I noticed that a few "#if"s could be removed from the Python code.
This patch is the result.
gdb/ChangeLog
2020-11-02 Tom Tromey <tromey@adacore.com>
* python/python.c: Consolidate two HAVE_PYTHON blocks.
(python_GdbModuleDef): Move earlier. Now static.
(do_start_initialization): Consolidate some IS_PY3K blocks.
The C++ parts of gdb.base/print-file-var.exp failed to build with
Clang because the "-x c++" option added by gdb_compile caused the
compiler to attempt to parse .so files as C++. This commit splits
the compiler and linker options into separate lists, and switches
to building via build_executable_from_specs which can accommodate
this separation.
gdb/testsuite/ChangeLog:
* gdb.base/print-file-var.exp (test): Separate compiler and
linker options, and build using build_executable_from_specs
to accommodate this.
In commits 221db974e6 and
68d654afdf, these patches:
2020-06-24 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_compile): Pass "-x c++" explicitly when
compiling C++ programs.
2020-09-25 Gary Benson <gbenson@redhat.com>
* lib/gdb.exp (gdb_compile): Pass "-x c++" earlier, and only
for .c files.
attempted to fix problems with testcases that compile .c files
using the C++ compiler. These patches cause gdb_compile to add
"-x c++" to the compiler options when using Clang. This fix does
not work for gdb.base/print-file-var.exp, however, which attempts
to compile a .c input file to an executable linked with shared
libraries: the resulting command caused the compiler to attempt
to parse the .so files as C++. This commit causes gdb_compile
to reject this combination of options.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_compile): Inhibit passing "-x c++"
for .c files compiled as C++ with Clang if any shared
libraries are specified.
Clang fails to compile a number of files with the following warning:
unknown attribute 'noclone' ignored [-Wunknown-attributes]. This
commit adds a new header, lib/noclone.h, which defines the macro
ATTRIBUTE_NOCLONE accordingly, and updates the relevant testcases
to use it.
gdb/testsuite/ChangeLog:
* lib/attributes.h: New header.
* gdb.base/backtrace.c: Include the above. Replace
__attribute__(noclone)) with ATTRIBUTE_NOCLONE.
* gdb.base/infcall-nested-structs.c: Likewise.
* gdb.base/vla-optimized-out.c: Likewise.
Consider test-case gdb.dwarf2/fission-multi-cu.exp. It produces an executable
fission-multi-cu and a dwo file fission-multi-cu.dwo.
The file fission-multi-cu.dwo contains a .debug_line.dwo section, which
according to the DWARF v5 standard is a "specialized line number table" for
type units in the .debug_info.dwo section, and contains only the directory and
filename lists.
When reading the actual .debug_line.dwo section using readelf -w, we get:
...
The Directory Table is empty.
The File Name Table is empty.
No Line Number Statements.
...
So, the section does not contain any actual information. Furthermore, no
information is required because the .debug_line.dwo section does not contain
any type units.
This is confirmed by:
- re-doing the commands listed at the start of fission-multi-cu.S, which were
used as starting point for fission-multi-cu.S, and
- compiling the fission-multi-cu{1,2}.c files with clang -flto -g -gsplit-dwarf
In both cases, no .debug_line.dwo section is generated.
Remove the .debug_line.dwo section, to make it fit how split dwarf is actually
generated by clang.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-11-02 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/fission-multi-cu.S: Remove .debug_line.dwo section.
I noticed an issue with the RISC-V prologue scanning stack unwinder.
We currently read the frame base register (either $sp or $fp) as a
signed value. This means that the frame_id's stack_addr field will be
a signed value.
In other contexts though these registers are data pointers, and so are
unsigned.
There's not many places where this mismatch actually shows though, but
I did find one place. Consider this GDB session:
(gdb) maintenance set dwarf unwinders off
(gdb) set backtrace past-main on
...
(gdb) b main
Breakpoint 1 at 0x20400344: file main.c, line 86.
(gdb) run
...
(gdb) bt
#0 main () at main.c:86
#1 0x2040005c in _start () at start.S:59
Backtrace stopped: frame did not save the PC
(gdb) info frame 1
Stack frame at 0x80000a1c:
pc = 0x2040005c in _start (start.S:59); saved pc = <not saved>
Outermost frame: frame did not save the PC
caller of frame at 0x80000a1c
source language asm.
Arglist at 0x80000a1c, args:
Locals at 0x80000a1c, Previous frame's sp is 0x80000a1c
(gdb) frame address 0x80000a1c
No frame at address 0x80000a1c.
(gdb) frame address 0xffffffff80000a1c
#1 0x2040005c in _start () at start.S:59
59 call main
Notice that the 'info frame 1' reports that the frame is at
'0x80000a1c', this is the unsigned frame base value, but when I try
to select a frame using this address I can't.
The reason is that the frame_id for frame #1 actually has the
unsigned (and hence sign-extended) stack_addr value. When I use the
sign extended address I can correctly select the frame.
I propose changing the prologue scanning unwinder to read the frame
base as unsigned. After this in the above case I can now do this:
(gdb) frame address 0x80000a1c
#1 0x2040005c in _start () at start.S:59
59 call main
(gdb) frame address 0xffffffff80000a1c
No frame at address 0xffffffff80000a1c.
Which I think makes more sense.
This issue causes failures in gdb.base/frame-selection.exp if you
compile for RV32 with a linker script that places the stack in the
correct location, which are resolved by this patch.
gdb/ChangeLog:
* riscv-tdep.c (riscv_frame_cache): Read the frame base register
as an unsigned value.
I noticed a little diff when re-generating the configure file in this
directory.
sim/ChangeLog:
* bpf/configure: Re-generate.
Change-Id: Ieb26be2cc1be8108d4b08387255f45b57f288171
This patch reverts most of git commit 1e3b96fd6c, so IR symbols are
again not marked def_regular or ref_regular. That should be enough to
stop IR symbols from becoming dynamic. To mark as-needed shared
libraries referenced by IR symbols, use the referencing BFD rather
than the ref flags.
bfd/
PR 15146
PR 26314
PR 26530
PR 26806
* elflink.c (elf_link_add_object_symbols): Don't set def/ref flags
for plugin syms. Do allow plugin syms to mark as-needed libs.
ld/
PR 26806
* testsuite/ld-plugin/lto-19.h,
* testsuite/ld-plugin/lto-19a.c,
* testsuite/ld-plugin/lto-19b.c,
* testsuite/ld-plugin/lto-19c.c: New test.
* testsuite/ld-plugin/pr26806.c,
* testsuite/ld-plugin/pr26806.d: New test.
* testsuite/ld-plugin/lto.exp: Run them.
This changes end_psymtab_common to be a method on partial_symtab.
This seems a little cleaner to me.
gdb/ChangeLog
2020-11-01 Tom Tromey <tom@tromey.com>
* dbxread.c (dbx_end_psymtab): Update.
* dwarf2/read.c (process_psymtab_comp_unit_reader)
(build_type_psymtabs_reader): Update.
* xcoffread.c (xcoff_end_psymtab): Update.
* ctfread.c (scan_partial_symbols): Update.
* psymtab.c (sort_pst_symbols): Remove.
(partial_symtab::end): Rename from end_psymtab_common. Inline
sort_pst_symbols.
* psympriv.h (struct partial_symtab) <end>: New method.
(end_psymtab_common): Don't declare.
The "n_psyms" statistic in the per-objfile stats is not really needed,
but its use requires passing the objfile to add_psymbol. This patch
removes the field in favor of counting the psyms when needed.
Note that this is not exactly equivalent -- in the old approach, a
psymbol can in theory be created and then the psymtab discarded, which
would increment the counter. This does not seem very important to me.
I rewrote the code to count partial symbols; though TBH I think that
this information is not really very useful.
gdb/ChangeLog
2020-11-01 Tom Tromey <tom@tromey.com>
* symmisc.c (count_psyms): New function.
(print_objfile_statistics): Use it.
* psymtab.c (append_psymbol_to_list): Remove.
(partial_symtab::add_psymbol): Inline append_psymbol_to_list.
* objfiles.h (struct objstats) <n_psyms>: Remove.
init_psymbol_list is now empty, and so this removes it.
gdb/ChangeLog
2020-11-01 Tom Tromey <tom@tromey.com>
* dbxread.c (dbx_symfile_read): Update.
* dwarf2/read.c (dwarf2_build_psymtabs): Update.
* xcoffread.c (xcoff_initial_scan): Update.
* psympriv.h (init_psymbol_list): Don't declare.
* psymtab.c (init_psymbol_list): Remove.
The test program being used declares a fixed-point type
(Base_Fixed_Point_Type) Base_Fixed_Point_Type whose (scaled) range
is System.Min_Int .. System.Max_Int. is an unwarranted assumption because
the range is implementation-defined. It means the compiler is therefore
free to reject that declaration.
We noticed this while one of my coworkers was working on enhancing
GNAT to support 128bit integers. The bulk of the work has been done,
but one side-effect is that there is a small gap in this particular
area where the compiler is now rejecting this code. We will eventually
plug that gap, but in meantime, since the testcase itself doesn't really
need such a large range, this commit simply adjusts the test program
to use hard-coded bounds for the range whose value are more reasonable.
gdb/testsuite/ChangeLog:
* gdb.ada/fixed_points/fixed_points.adb: Replace use of
System.Min_Int and System.Max_Int with smaller hardcoded
constants.
This commit renames gnat_encoded_fixed_type_info into
gnat_encoded_fixed_point_type_info, so as to be more consistent
with the naming used for the other associated routines (i.e.
use "fixed_point" rather than just "fixed").
gdb/ChangeLog:
* ada-lang.c (gnat_encoded_fixed_point_type_info): Renames
gnat_encoded_fixed_type_info. Update all callers.
One of the lines got too long after a renaming done in a previous
commit. This fixes that.
gdb/ChangeLog:
* ada-lang.c (cast_from_gnat_encoded_fixed_point_type): Split
line too long.
This patch renames some of the fixed-point-related subprograms in ada-lang.c
so as to make it obvious that those routines only handle the case where
the types are encoded using the GNAT encoding.
No function change; this patch is preparation work for adding support
for fixed-point types purely based on standard DWARF debug info.
gdb/ChangeLog:
* ada-lang.c (cast_from_gnat_encoded_fixed_point_type): Renames
cast_from_fixed. Update all callers.
(cast_to_gnat_encoded_fixed_point_type): Renames cast_to_fixed.
Update all callers.
(gnat_encoded_fixed_point_scaling_factor): Renames ada_scaling_factor.
Update all callers.
* ada-lang.h (gnat_encoded_fixed_point_scaling_factor): Renames
ada_scaling_factor.
* ada-typeprint.c: Replace call to ada_scaling_factor by call
to print_gnat_encoded_fixed_point_type.
* ada-valprint.c: Likewise.
This partially reverts some parts of the commit:
commit 17417fb0ec
Date: Sat Oct 31 09:01:25 2020 -0400
gdb, gdbsupport: add debug_prefixed_printf, remove boilerplate functions
This commit removed 3 places where some debug flags were being
checked. The result was that debug tracing was being printed
unconditionally.
This commit adds back the 3 flag checks.
gdb/ChangeLog:
* infrun.h (infrun_debug_printf): Add check of debug_infrun flag.
(debug_prefixed_printf): Add check of debug_displaced flag.
* linux-nat.c (linux_nat_debug_printf): Add check of
debug_linux_nat flag.
The *_debug_print_1 functions are all very similar, the only difference
being the subsystem name. Remove them all and make the logging macros
use a new debug_prefixed_printf function directly.
gdb/ChangeLog:
* infrun.c (infrun_debug_printf_1): Remove.
(displaced_debug_printf_1): Remove.
(stop_all_threads): Use debug_prefixed_printf.
* infrun.h (infrun_debug_printf_1): Remove.
(infrun_debug_printf): Use debug_prefixed_printf.
(displaced_debug_printf_1): Remove.
(displaced_debug_printf): Use debug_prefixed_printf.
* linux-nat.c (linux_nat_debug_printf_1): Remove.
(linux_nat_debug_printf): Use debug_prefixed_printf.
gdbsupport/ChangeLog:
* common-debug.cc (debug_prefixed_printf): New.
* common-debug.h (debug_prefixed_printf): New declaration.
* event-loop.cc (event_loop_debug_printf_1): Remove.
* event-loop.h (event_loop_debug_printf_1): Remove.
(event_loop_debug_printf): Use debug_prefixed_printf.
(event_loop_ui_debug_printf): Use debug_prefixed_printf.
Change-Id: Ib323087c7257f0060121d302055c41eb64aa60c6
... with AC_COMPILE_IFELSE and AC_LANG_PROGRAM.
All changes in the generated configure file are insignificant
whitespace changes.
gdbserver/ChangeLog:
* acinclude.m4: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE +
AC_LANG_PROGRAM.
* configure: Re-generate.
Change-Id: Idab8b5e1a984046b5283940c02e5a22da2291d58
... with AC_LINK_IFELSE + AC_LANG_PROGRAM.
All changes in the generated configure file are insignificant whitespace
changes.
gdb/ChangeLog:
* configure: Re-generate.
* sanitize.m4: Replace AC_TRY_LINK with AC_LINK_IFELSE +
AC_LANG_PROGRAM.
Change-Id: I6fc4c39e10b28d2ade964e0d59a7f8ec0d3a272a
autoupdate does this change, it fixes this warning:
configure.ac:50: warning: The macro `AC_FUNC_VFORK' is obsolete.
configure.ac:50: You should run autoupdate.
../../lib/autoconf/functions.m4:1944: AC_FUNC_VFORK is expanded from...
common.m4:20: GDB_AC_COMMON is expanded from...
configure.ac:50: the top level
There are not changes in the generated configure files.
gdbsupport/ChangeLog:
* common.m4: Replace AC_FUNC_VFORK with AC_FUNC_FORK.
Change-Id: I9de9f718c57e6d51c9734161f36c36ce39170325
For some reason, autoupdate isn't able to grok ptrace.m4:
$ autoupdate ptrace.m4
/usr/bin/m4:/tmp/auYjuodw/input.m4:171: ERROR: end of file in string
autoupdate: /usr/bin/m4 failed with exit status: 1
Honestly, I'm unable to grok it either. This patch re-indents it in a
way that I think is easier to read. With this patch applied, autoupdate
becomes able to parse ptrace.m4, but I chose to keep this re-indent in a
patch of its own.
All the changes in generated configure files consist of insignificant
whitespace changes.
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
* ptrace.m4: Re-indent.
Change-Id: Ie2afab09fecc8b6d0cccccb47ac9756f3843881e
Run autoupdate, the only change is to split AC_INIT into AC_INIT and
AC_CONFIG_SRCDIR.
gdb/testsuite/ChangeLog:
* configure.ac: Split AC_INIT into AC_INIT and AC_CONFIG_SRCDIR.
* configure: Re-generate.
Change-Id: I6e40c0261bda4fe9144b896799ef460d23e22e09
Run autoupdate on configure.ac and adjust the indentation of the result
for better readability. This removes a bunch of warnings when running
`autoreconf -vf -Wall`. The changes are:
* Replace AC_INIT with AC_INIT and no arguments plus
AC_CONFIG_SRCDIR.
* Replace AC_ERROR with AC_MSG_ERROR.
* Replace AC_TRY_LINK with AC_LINK_IFELSE.
* Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE.
* Replace AC_HELP_STRING with AS_HELP_STRING.
autoupdate erroneously tries to replace AC_C_LONG_DOUBLE in a comment,
which I reverted manually.
All the changes in the generated configure file are insignificant
whitespaces changes.
gdb/ChangeLog:
* configure.ac: Modernize.
* configure: Re-generate.
Change-Id: Ie3a1409c8032a36a6383da964286a46ece9b546e
Run autoupdate on gdbserver/configure.ac and then tweak it to use easier
to read indentation. This removes a few warnings when running
`autoreconf -vf -Wall`.
* Replace AC_INIT with AC_INIT and no arguments plus AC_CONFIG_SRCDIR.
* Replace AC_GNU_SOURCE with AC_USE_SYSTEM_EXTENSIONS.
* Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE.
* Replace AC_TRY_LINK with AC_LINK_IFELSE.
autoupdate gets it right, except this one here:
--- a/gdbserver/configure.ac
+++ b/gdbserver/configure.ac
@@ -304,7 +304,7 @@ if test "$srv_linux_thread_db" = "yes"; then
AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[]])],[found="-Wl,--dynamic-list"
RDYNAMIC='-Wl,--dynamic-list=$(srcdir)/proc-service.list'],[RDYNAMIC="-rdynamic"
LDFLAGS="$old_LDFLAGS $RDYNAMIC"
- AC_TRY_LINK([], [],
+ _au_m4_changequote([,])AC_TRY_LINK([], [],
[found="-rdynamic"],
[found="no"
RDYNAMIC=""])])
... which I had to convert manually.
The changes in the generated configure file only contain insignificant
whitespace changes, so that gives confidence that the conversion is
correct.
gdbserver/ChangeLog:
* configure.ac: Modernize.
* configure: Re-generate.
Change-Id: Ia769aaec2aafac595504f477da955e91dffa4d8f
