GDB was failing to catch cases where a corrupt ELF or core file
contained an invalid length value in a Dwarf debug frame FDE header.
It was checking for buffer overflow but not cases where the length was
negative or caused pointer wrap-around.
In addition to the additional validity check, this patch cleans up the
multiple signed/unsigned conversions on the length field so that an
unsigned representation is used consistently throughout.
This patch fixes CVE-2017-9778 and PR gdb/21600.
2019-04-25 Sandra Loosemore <sandra@codesourcery.com>
Kang Li <kanglictf@gmail.com>
PR gdb/21600
* dwarf2-frame.c (read_initial_length): Be consistent about using
unsigned representation of length.
(decode_frame_entry_1): Likewise. Check for wraparound of
end pointer as well as buffer overflow.
This patch aims to improve the definitions of BTI and PAC based PLTs.
The following changes are made:
* PLT0 does not need PAC instructions since the PLTGOT[2] (and PLTGOT[1])
are readonly so they cannot be corrupted at runtime. Thus both PAC plt0
and BTI+PAC plt0 are removed and we can use basic plt0 and BTI plt0
instead, respectively.
* We can remove the extra padding nops when we add the new bti instructions.
BTI plt0 and BTI TLSDESC plt are updated.
* For better performance PLTn could be padded to 24bytes. Both BTI pltn and
PAC pltn are updated.
*** bfd/ChangeLog ***
2019-04-25 Sudakshina Das <sudi.das@arm.com>
* elfnn-aarch64.c (PLT_BTI_ENTRY_SIZE): Remove.
(PLT_BTI_TLSDESC_ENTRY_SIZE): Remove.
(PLT_PAC_ENTRY_SIZE, PLT_BTI_PAC_ENTRY_SIZE): Remove.
(PLT_BTI_SMALL_ENTRY_SIZE, PLT_PAC_SMALL_ENTRY_SIZE): Update.
(elfNN_aarch64_small_plt0_pac_entry): Remove.
(elfNN_aarch64_small_plt0_bti_pac_entry): Remove.
(elfNN_aarch64_small_plt0_bti_entry): Update.
(elfNN_aarch64_small_plt_bti_entry): Update.
(elfNN_aarch64_small_plt_pac_entry): Update.
(elfNN_aarch64_tlsdesc_small_plt_bti_entry): Update.
(setup_plt_values): Setup new entries.
(elfNN_aarch64_finish_dynamic_sections): Remove size change.
(elfNN_aarch64_plt_sym_val): Likewise.
*** ld/ChangeLog ***
2019-04-25 Sudakshina Das <sudi.das@arm.com>
* testsuite/ld-aarch64/bti-pac-plt-1.d: Update.
* testsuite/ld-aarch64/bti-pac-plt-2.d: Update.
* testsuite/ld-aarch64/bti-plt-1.d: Update.
* testsuite/ld-aarch64/bti-plt-3.d: Update.
* testsuite/ld-aarch64/bti-plt-5.d: Update.
* testsuite/ld-aarch64/pac-plt-1.d: Update.
* testsuite/ld-aarch64/pac-plt-2.d: Update.
Complement commit 1586d91e32 ("/ 0 should send SIGFPE not SIGTRAP..."),
<https://sourceware.org/ml/binutils/2004-07/msg00260.html>, and update a
stale comment referring the 20-bit code field of the BREAK and SDBBP
instructions, by making it explicit that where permitted by choosing the
MIPS32 or a later ISA the whole field can now be set with a single
operand for the SDBBP instruction only.
include/
* opcode/mips.h: Update comment for MIPS32 CODE20 operand.
Targets such as xtensa incur a much higher overhead to resolve
location view numbers than e.g. x86, because the expressions used to
compute view numbers cannot be resolved soon enough.
Each view number is computed by incrementing the previous view, if
they are both at the same address, or by resetting it to zero
otherwise. If PV is the previous view number, PL is its location, and
NL is the location of the next view, its number is computed by
evaluating NV = !(NL > PL) * (PV + 1).
set_or_check_view uses resolve_expression to decide whether portions
of this expression can be simplified to constants. The (NL > PL)
subexpression is one that can often be resolved to a constant,
breaking chains of view number computations at instructions of nonzero
length, but not after alignment that might be unnecessary.
Alas, when nearly every frag ends with a relaxable instruction,
frag_offset_fixed_p will correctly fail to determine a known offset
between two unresolved addresses in neighboring frags, so the
unresolved symbolic operation will be constructed and used in the
computation of most view numbers. This results in very deep
expressions.
As view numbers get referenced in location view lists, each operand in
the list goes through symbol_clone_if_forward_ref, which recurses on
every subexpression. If each view number were to be referenced, this
would exhibit O(n^2) behavior, where n is the depth of the view number
expressions, i.e., the length of view number sequences without an
early resolution that cuts the expression short.
This patch enables address compares used by view numbering to be
resolved even when exact offsets are not known, using new logic to
determine when the location either remained the same or changed for
sure, even with the possibility of relaxation. This enables most view
number expressions to be resolved with a small, reasonable depth.
PR gas/24444
* frags.c (frag_gtoffset_p): New.
* frags.h (frag_gtoffset_p): Declare it.
* expr.c (resolve_expression): Use it.
This changes the gdb test suite to omit -fno-stack-protector when
compiling Rust code. This makes Rust testing work again.
I think I saw this patch somewhere already, but I couldn't find it
again just now, so I'm checking this version in.
gdb/testsuite/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* lib/gdb.exp (gdb_compile): Don't add -fno-stack-protector for
Rust.
The ld testsuite includes numerous tests that depend on being able to
compile and link programs with the C compiler. Some of these tests
use [which $CC] to check for the presence of the compiler before
proceeding with the test, but run_ld_link_exec_tests and run_cc_link_tests
give ERRORs if compilation fails. Also, even if $CC is defined and present,
it may not be usable due to missing libraries, etc.
This patch adds a new procedure check_compiler_available that attempts
to build an empty program and caches the result. Uses of [which $CC]
are replaced with calls to this procedure, and run_ld_link_exec_tests
and run_cc_link_tests now also guard attempts to use $CC.
2019-04-24 Sandra Loosemore <sandra@codesourcery.com>
ld/
* testsuite/config/default.exp: Use [check_compiler_available]
instead of [which $CC].
* testsuite/ld-auto-import/auto-import.exp: Likewise.
* testsuite/ld-cygwin/exe-export.exp: Likewise.
* testsuite/ld-elf/audit.exp: Likewise.
* testsuite/ld-elf/compress.exp: Likewise.
* testsuite/ld-elf/dwarf.exp: Likewise.
* testsuite/ld-elf/elf.exp: Likewise.
* testsuite/ld-elf/indirect.exp: Likewise.
* testsuite/ld-elf/linux-x86.exp: Likewise.
* testsuite/ld-elf/shared.exp: Likewise.
* testsuite/ld-elf/tls.exp: Likewise.
* testsuite/ld-elf/wrap.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-i386/i386.exp: Likewise.
* testsuite/ld-i386/no-plt.exp: Likewise.
* testsuite/ld-i386/tls.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-sh/sh.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.
* testsuite/ld-size/size.exp: Likewise.
* testsuite/ld-srec/srec.exp: Likewise.
* testsuite/ld-undefined/undefined.exp: Likewise.
* testsuite/ld-unique/unique.exp: Likewise.
* testsuite/ld-x86-64/mpx.exp: Likewise.
* testsuite/ld-x86-64/no-plt.exp: Likewise.
* testsuite/ld-x86-64/tls.exp: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/lib/ld-lib.exp (run_ld_link_exec_tests): Call
check_compiler_available before trying to use the compiler.
(run_cc_link_tests): Likewise.
(check_compiler_available): New. Use it instead of [which $CC].
While trying to build GDB on i686, I found the following error:
In file included from ../../gdb/common/common-defs.h:105,
from ../../gdb/defs.h:28,
from ../../gdb/aarch64-tdep.c:21:
../../gdb/aarch64-tdep.c: In function 'gdbarch* aarch64_gdbarch_init(gdbarch_info, gdbarch_list*)':
../../gdb/aarch64-tdep.c:3176:43: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'uint64_t' {aka 'long long unsigned int'} [-Werror=format=]
3176 | internal_error (__FILE__, __LINE__, _("VQ out of bounds: %ld (max %d)"),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/common/gdb_locale.h:28:29: note: in definition of macro '_'
28 | # define _(String) gettext (String)
| ^~~~~~
../../gdb/aarch64-tdep.c:3176:64: note: format string is defined here
3176 | internal_error (__FILE__, __LINE__, _("VQ out of bounds: %ld (max %d)"),
| ~~^
| |
| long int
| %lld
This happens because aarch64-tdep.c:aarch64_gdbarch_init prints a
"uint64_t" variable using "%ld". This patch fixes the build by using
"pulongest" instead. As explained in a similar fix (commit
495143533a), this should be safe because
if aarch64-tdep.c is included in the build, then ULONGEST must be a
64-bit type.
gdb/ChangeLog:
2019-04-24 Sergio Durigan Junior <sergiodj@redhat.com>
* aarch64-tdep.c (aarch64_gdbarch_init): Use "pulongest" to print
"vq".
Commit 4aa866af ("Fix AMD64 return value ABI in expression
evaluation") introduced a regression when calling a function with a
structure that contains bitfields.
Because the caller of amd64_has_unaligned_fields handles bitfields
already, it seemed to me that the simplest fix was to ignore bitfields
here.
gdb/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* amd64-tdep.c (amd64_has_unaligned_fields): Ignore bitfields.
gdb/testsuite/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* gdb.arch/amd64-eval.exp: Test bitfield return.
* gdb.arch/amd64-eval.cc (struct Bitfields): New.
(class Foo) <return_bitfields>: New method.
(main): Call it.
* objcopy.c (strip_main): Do not enable note merging by default if
just stripping debug or dwo information.
* doc/binutils.texi (strip): Update documentation.
In most cases we don't want expression symbols, such as that created
for an expression like "symbol + (1f - .)", resolved down to a
constant. Instead we'd like to leave the expression as "symbol +
constant" once the "1f - ." part has been resolved, and let the
backend decide whether "symbol" can be reduced further.
However, that doesn't work when trying to resolve .loc view symbols
early. We get expression symbols left as an O_symbol expression
pointing at an absolute symbol, and marked as sy_flags.sy_resolved.
That wouldn't really be a problem, but when one of those expression
symbols is used in further .loc view expressions, its value is taken
as zero.
This patch fixes the symbol value mistake, and stops creation of
O_symbol expression symbols pointing to absolute symbols. Either of
these fixes would cure the .loc view usage.
PR 24444
* symbols.c (resolve_symbol_value): When handling symbols
marked as sy_flags.resolved, return correct value for the
case of expression symbols left as an O_symbol expression.
Merge O_symbol code handling undefined and common symbols with
code handling special cases of expression symbols. Use
seg_left to test for undefined and common symbols. Don't
leave an O_symbol expression when X_add_symbol resolves to
the absolute_section. Init final_val later.
* testsuite/gas/mmix/basep-7.d: Adjust expected output.
Make use of the default gdbarch methods for gdbarch_unwind_pc, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* s12z-tdep.c (s12z_unwind_pc): Delete.
(s12z_unwind_sp): Delete.
(s12z_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_unwind_sp where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rl78-tdep.c (rl78_unwind_sp): Delete.
(rl78_gdbarch_init): Don't register deleted function with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* xstormy16-tdep.c (xstormy16_unwind_sp): Delete.
(xstormy16_unwind_pc): Delete.
(xstormy16_dummy_id): Delete.
(xstormy16_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_unwind_pc where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* vax-tdep.c (vax_unwind_pc): Delete.
(vax_gdbarch_init): Don't register deleted function with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* v850-tdep.c (v850_unwind_sp): Delete.
(v850_unwind_pc): Delete.
(v850_dummy_id): Delete.
(v850_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* tilegx-tdep.c (tilegx_unwind_sp): Delete.
(tilegx_unwind_pc): Delete.
(tilegx_unwind_dummy_id): Delete.
(tilegx_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* tic6x-tdep.c (tic6x_unwind_sp): Delete.
(tic6x_dummy_id): Delete.
(tic6x_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_unwind_pc where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* sparc-tdep.c (sparc_unwind_pc): Delete.
(sparc32_gdbarch_init): Don't register deleted function with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* sh-tdep.c (sh_unwind_sp): Delete.
(sh_unwind_pc): Delete.
(sh_dummy_id): Delete.
(sh_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* score-tdep.c (score_unwind_sp): Delete.
(score_unwind_pc): Delete.
(score_dummy_id): Delete.
(score_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rx-tdep.c (rx_unwind_pc): Delete.
(rx_unwind_sp): Delete.
(rx_dummy_id): Delete.
(rx_gdbarch_init): Don't register deleted functions with
gdbarch. Update comment.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* rs6000-tdep.c (rs6000_unwind_pc): Delete.
(rs6000_dummy_id): Delete.
(rs6000_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch method gdbarch_dummy_id where
possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
This commit leaves or1k_unwind_sp and or1k_unwind_pc in place. These
functions do match the default methods except that they add additional
debugging code. In order to preserve the debug I have left these
functions unchanged.
gdb/ChangeLog:
* or1k-tdep.c (or1k_dummy_id): Delete.
(or1k_gdbarch_init): Don't register deleted function with gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* nios2-tdep.c (nios2_dummy_id): Delete.
(nios2_unwind_sp): Delete.
(nios2_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* nds32-tdep.c (nds32_dummy_id): Delete.
(nds32_unwind_pc): Delete.
(nds32_unwind_sp): Delete.
(nds32_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* msp430-tdep.c (msp430_unwind_pc): Delete.
(msp430_unwind_sp): Delete.
(msp430_dummy_id): Delete.
(msp430_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* moxie-tdep.c (moxie_unwind_sp): Delete.
(moxie_unwind_pc): Delete.
(moxie_dummy_id): Delete.
(moxie_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* mn10300-tdep.c (mn10300_dummy_id): Delete.
(mn10300_unwind_pc): Delete.
(mn10300_unwind_sp): Delete.
(mn10300_push_dummy_call): Use gdbarch_unwind_sp not
mn10300_unwind_sp.
(mn10300_frame_unwind_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* mep-tdep.c (mep_unwind_pc): Delete.
(mep_unwind_sp): Delete.
(mep_dummy_id): Delete.
(mep_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_unwind_pc, and
gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m68hc11-tdep.c (m68hc11_unwind_pc): Delete.
(m68hc11_unwind_sp): Delete.
(m68hc11_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m32r-tdep.c (m32r_unwind_sp): Delete.
(m32r_unwind_pc): Delete.
(m32r_dummy_id): Delete.
(m32r_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* m32c-tdep.c (m32c_unwind_pc): Delete.
(m32c_unwind_sp): Delete.
(m32c_dummy_id): Delete.
(m32c_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/lm32-tdep.c (lm32_unwind_sp): Delete.
(lm32_unwind_pc): Delete.
(lm32_dummy_id): Delete.
(lm32_gdbarch_init): Don't register deleted functions with
gdbarch.
Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.
I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.
gdb/ChangeLog:
* gdb/iq2000-tdep.c (iq2000_unwind_sp): Delete.
(iq2000_unwind_pc): Delete.
(iq2000_dummy_id): Delete.
(iq2000_gdbarch_init): Don't register deleted functions with
gdbarch.
The general type_align method should be a suitable alternative to
nds32_type_align, so switch to use that.
The only change this will introduce is related to static fields in a
struct or union, the existing code doesn't take account of static
fields when computing the alignment for structs of unions, though this
is probably a bug - which would probably be exposed by the test case
gdb.cp/many-args.exp, though I don't have any way to test this target
right now.
gdb/ChangeLog:
* nds32-tdep.c (nds32_type_align): Delete.
(nds32_push_dummy_call): Use type_align instead.
Replaces use of arm_type_align with common type_align function.
Doing this fixes a bug in arm_type_align where static fields are
considered as part of the alignment calculation of a struct, which
results in arguments passed on the stack being misaligned, this bug
was causing a failure in gdb.cp/many-args.exp.
Part of the old arm_type_align is retained and used as the gdbarch
type align callback in order to correctly align vectors.
gdb/ChangeLog:
* arm-tdep.c (arm_type_align): Only handle vector override case.
(arm_push_dummy_call): Use type_align.
(arm_gdbarch_init): Register arm_type_align gdbarch function.
Replaces use of aarch64_type_align with common type_align function.
Doing this fixes a bug in aarch64_type_align where static fields are
considered as part of the alignment calculation of a struct, which
results in arguments passed on the stack being misaligned. This bug
is exposed in the new test gdb.cp/many-args.exp.
Part of the old aarch64_type_align is retained and used as the gdbarch
type align callback in order to correctly align vectors.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_type_align): Only handle vector override
case.
(pass_on_stack): Use type_align.
(aarch64_gdbarch_init): Register aarch64_type_align gdbarch
function.
gdb/testsuite/ChangeLog:
* gdb.cp/many-args.cc: New file.
* gdb.cp/many-args.exp: New file.
I noticed that one of the overloads of line_header::file_name_at is
unused. This patch removes it.
gdb/ChangeLog
2019-04-23 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (line_header::file_name_at): Remove unused
overload.
When running gdb.btrace/reconnect.exp with native-gdbserver, we run into:
...
FAIL: gdb.btrace/reconnect.exp: first: stepi 19
...
due to the fact that we're trying to match:
...
stepi 19^M
0x00007ffff7dd8b57 in _dl_start () from /lib64/ld-linux-x86-64.so.2^M
...
using pattern:
...
gdb_test "stepi 19" "0x.* in .* from target.*"
...
Fix this by changing the pattern to:
...
gdb_test "stepi 19" "0x.* in .* from .*"
...
Tested on x86_64-linux with native and native-gdbserver.
gdb/testsuite/ChangeLog:
2019-04-23 Tom de Vries <tdevries@suse.de>
PR gdb/24433
* gdb.btrace/reconnect.exp: Fix stepi 19 pattern.
The -m option of cc-with-tweaks.sh sets want_multi to true, invoking dwz like
this:
...
elif [ "$want_multi" = true ]; then
cp $output_file ${output_file}.alt
$DWZ -m ${output_file}.dwz "$output_file" ${output_file}.alt \
> /dev/null 2>&1
fi
...
The problem that is being solved here, is that we want to test dwz in
multifile mode, which requires more than one input file, while we only have
(at the scope of cc-with-tweaks.sh) one executable. We handle this by copying
the executable and offering this as a second input (and using a copy has the
additional benefit that it maximally enables dwz transformation).
However, after the dwz invocation, the copy is no longer used, and the
presence of the file actually causes a test regression:
...
FAIL: gdb.base/jit-so.exp: test jit-reader-load filename completion
...
Fix this by removing the superflous copy after dwz invocation.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-04-23 Tom de Vries <tdevries@suse.de>
PR gdb/24438
* contrib/cc-with-tweaks.sh: Remove superfluous .alt file after dwz
invocation.
Ubuntu/Debian defaults PIE to enabled. This causes the trace tests
to fall over due to variables being returned as "unavailable". The
tests were never designed to work with pie.
Simply ensure the nopie flag is always used for the failing tests.
This removes 100+ failures when running native-gdbserver on Ubuntu 18.04.
gdb/testsuite/ChangeLog:
* gdb.trace/backtrace.exp: Use nopie flag.
* gdb.trace/circ.exp: Likewise.
* gdb.trace/collection.exp: Likewise.
* gdb.trace/ftrace.exp: Likewise.
* gdb.trace/mi-trace-unavailable.exp: Likewise.
* gdb.trace/mi-traceframe-changed.exp: Likewise.
* gdb.trace/qtro.exp: Likewise.
* gdb.trace/read-memory.exp: Likewise.
* gdb.trace/report.exp: Likewise.
* gdb.trace/tfile.exp: Likewise.
* gdb.trace/tfind.exp: Likewise.
* gdb.trace/unavailable.exp: Likewise.
Commit c40e31a121 broke --enable-dependency-tracking=no.
* Makefile.am (GENDEPDIR): New var, used..
(GENSCRIPTS): ..here.
* Makefile.in: Regenerate.
* genscripts.sh: Test for $DEPDIR set before every use.
DW_OP_addrx is the new name of DW_OP_GNU_addr_index, and DW_FORM_addrx
is the name of DW_FORM_addr_index in the Dwarf 5 standard. This is a small
step towards supporting Dwarf 5 in gdb.
Note: I could not find any tests specifically for *_GNU_addr_index, and
I did not add any new tests, please advise.
