I assume this mode was needed when EVEX.W handling wasn't really correct
yet for other than 64-bit mode. It's clearly not needed anymore. Its
elimination also allows dropping the EVEX.W split of VCVT{,U}SI2SS. (For
the record, the dropped mode would have been wrong if used in any table
entry not already guaranteeing EVEX.W=1.)
The only meaningful difference from OP_I() is the handling of the
VEX.W=1 case in 64-bit mode for bytemode being v_mode. Funnel
everything else into OP_I(), and drop no longer needed local
variables.
MOVNTI was wrongly assembled with a 66h prefix. Add IgnoreSize to
address this. It and the scalar to/from integer conversion insns also
were also wrongly using Ev / Gv, leading to 16-bit register names being
printed when 32-bit ones were meant.
Clone the 32-bit SSE2 test to cover both assembler and disassembler.
This patch corrects ppc rs_align_code handling to choose the alignment
nops based on the machine in force at the alignment directive rather
than the machine at the end of file.
* config/tc-ppc.h (ppc_nop_select): Declare.
(NOP_OPCODE): Define.
* config/tc-ppc.c (ppc_elf_end, ppc_xcoff_end): Zero ppc_cpu.
(ppc_nop_encoding_for_rs_align_code): New enum.
(ppc_nop_select): New function.
(ppc_handle_align): Don't use ppc_cpu here. Get nop type from frag.
* testsuite/gas/ppc/groupnop.d,
* testsuite/gas/ppc/groupnop.s: New test.
* testsuite/gas/ppc/ppc.exp: Run it.
2019-06-24 Ilia Diachkov <ilia.diachkov@optimitech.com>
bfd/
* elfnn-riscv.c (_bfd_riscv_relax_lui): Delete early exit when
SEC_MERGE or SEC_CODE flags are set.
(_bfd_riscv_relax_section): New local symtype. Set sym_sec and
symtype consistently. Don't include sec_addr (sym_sec) in symval.
Add check for SEC_INFO_TYPE_MERGE and call _bfd_merged_section_offset.
Add sec_addr (sym_sec) after handling merge sections.
commit d2ef37ebd9
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Fri Dec 7 08:30:30 2018 -0800
elf: Report property change when merging properties
failed to remove the property after reporting it has been removed. This
patch corrects it.
bfd/
PR ld/24721
* elf-properties.c (elf_merge_gnu_property_list): Remove the
property after reporting property removal.
ld/
PR ld/24721
* testsuite/ld-x86-64/x86-64.exp: Run PR ld/24721 tests.
* testsuite/ld-x86-64/pr24721-x32.d: New file.
* testsuite/ld-x86-64/pr24721.d: Likewise.
* testsuite/ld-x86-64/pr24721.map: Likewise.
* testsuite/ld-x86-64/pr24721a.s: Likewise.
* testsuite/ld-x86-64/pr24721b.s: Likewise.
When running gdb.dwarf2/implptr-64bit.exp with board cc-with-dwz-m, we run into:
...
dwz: dwz.c:2363: checksum_die: \
Assertion `\
((!op_multifile && !rd_multifile && !fi_multifile) || cu != die_cu (ref)) \
&& (!op_multifile || cu->cu_chunk == die_cu (ref)->cu_chunk)' failed.
cc-with-tweaks.sh: line 218: 13030 Aborted \
$DWZ -m ${output_file}.dwz "$output_file" ${output_file}.alt > /dev/null
...
In other words, PR dwz/24170.
The trigger for the dwz PR is when intra-CU references are encoded using
section-relative encoding DW_FORM_ref_addr, but could have been encoded using
CU-relative encoding DW_FORM_ref4.
Fix the intra-CU '%' label reference in implptr-64bit.exp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/implptr-64bit.exp: Fix intra-CU '%' label reference.
When running gdb.trace/{entry-values.exp,unavailable-dwarf-piece.exp} with
board cc-with-dwz, we run into two failures related to the DW_AT_decl_file
attribute:
- The encoding DW_FOR_sdata is used for DW_AT_decl_file, while the attribute
is required to have a an "unsigned integer constant" value.
- The DW_AT_decl_file attributes refer to a file with index one, while there's
no such file.
Fix this by using DW_FOR_udata and the value 0, meaning "no file specified".
Tested on x86_64-linux with board native-gdbserver.
gdb/testsuite/ChangeLog:
2019-06-24 Tom de Vries <tdevries@suse.de>
* gdb.trace/entry-values.exp: Use DW_FORM_udata instead of
DW_FOR_sdata for DW_AT_decl_file. Use 0 for DW_AT_decl_file.
* gdb.trace/unavailable-dwarf-piece.exp: Same.
When running gdb.dwarf2/inlined_subroutine-inheritance.exp with board
cc-with-dwz, we run into:
...
dwz: inlined_subroutine-inheritance: Couldn't find DIE referenced by \
DW_AT_abstract_origin
...
The problem is that the DW_AT_abstract_origin attributes refer to DIEs in
other CUs, while the references are encoded using the cu-relative encoding
DW_FORM_ref4.
Fix this by forcing the references to use DW_FORM_ref_addr.
Tested on x86_64-linux.
Tested with commit c24bdb023c "Introduce dwarf2_cu::get_builder" reverted,
and verified that the test-case fails in the same way before and after this
patch.
gdb/testsuite/ChangeLog:
2019-06-24 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/inlined_subroutine-inheritance.exp:
While the skiboot linker script bears some culpability in this PR,
it's also true that the GOT indirect to GOT relative optimisation for
16-bit offsets isn't safe. At least, it isn't safe to remove the GOT
entry based on distance between the GOT pointer and symbol calculated
from the preliminary layout. So this patch removes that optimisation,
and reduces the range allowed for 32-bit and 34-bit offsets.
PR 24704
bfd/
* elf64-ppc.c (R_PPC64_GOT16_DS): Don't set has_gotrel.
(ppc64_elf_edit_toc): Don't remove R_PPC64_GOT16_DS got entries.
Reduce range of offsets allowed for other GOT relocs.
ld/
* testsuite/ld-powerpc/elfv2exe.d: Update.
* testsuite/ld-powerpc/elfv2so.d: Update.
Depending on optimisation level and gcc version, git commit 890f750a3b
introduces a false positive warning that i_shdrp may be used
uninitialized.
PR 24689
* elfcode.h (elf_object_p): Warning fix.
tui_first_data_element_no_in_line is never used. This patch removes
it. Tested by rebuilding, and by grep.
gdb/ChangeLog
2019-06-22 Tom Tromey <tom@tromey.com>
* tui/tui-windata.h (tui_first_data_element_no_in_line): Don't
declare.
* tui/tui-windata.c (tui_first_data_element_no_in_line): Remove.
This removes two unused functions from the TUI. According to
"git grep -G", they have never been used.
gdb/ChangeLog
2019-06-22 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (tui_del_window, tui_del_data_windows): Don't
declare.
* tui/tui-data.c (tui_del_window, tui_del_data_windows): Remove.
When building gdb on s390x with -m31, we run into this Wformat
warning (which Werror turns into an error):
...
gdb/dwarf2read.c: In function \
'void create_addrmap_from_aranges(dwarf2_per_objfile*, \
dwarf2_section_info*)':
gdb/dwarf2read.c:3277:22: error: format '%zu' expects argument of type \
'size_t', but argument 3 has type 'int' [-Werror=format=]
warning (_("Section .debug_aranges in %s entry at offset %zu "
...
The Wformat warning is triggered in this statement:
...
warning (_("Section .debug_aranges in %s entry at offset %zu "
"length %s exceeds section length %s, "
"ignoring .debug_aranges."),
objfile_name (objfile), entry_addr - section->buffer,
plongest (bytes_read + entry_length),
pulongest (section->size));
...
where 'entry_addr - section->buffer' is of type ptrdiff_t and '%zu' prints an
unsigned with the same size as size_t/ssize_t.
On s390x with -m31, we have:
- size_t : unsigned long int (32-bit)
- ptrdiff_t: int (32-bit)
Wformat warns against this because even though long int and int have the same
size, the types are not compatible.
[ The Wformat warning is to similar to what we would get for x86_64 -m32
(where long and int are also the same size) and:
...
int i;
printf ("%ld", i);
... ]
Fix this by using '%s' and plongest instead of '%zu' to print ptrdiff_t.
Build and reg-tested on x86_64.
gdb/ChangeLog:
2019-06-22 Tom de Vries <tdevries@suse.de>
* dwarf2read.c (create_addrmap_from_aranges)
(read_debug_names_from_section): Print ptrdiff_t using '%s' and plongest
instead of '%zu'.
When testing gdb.base/index-cache.exp using a gcc build without
--enable-linker-build-id we get:
...
FAIL: gdb.base/index-cache.exp: \
test_cache_enabled_miss: at least one file was created
FAIL: gdb.base/index-cache.exp: \
test_cache_enabled_miss: couldn't get executable build id
FAIL: gdb.base/index-cache.exp: \
test_cache_enabled_hit: check index-cache stats
...
With "set debug index-cache on" we find:
...
(gdb) file index-cache
Reading symbols from index-cache...
index cache: objfile index-cache has no build id
...
The problem is that a build-id is required for the index-cache functionality.
Fix this by compiling index-cache.c with -Wl,--build-id.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-21 Tom de Vries <tdevries@suse.de>
* gdb.base/index-cache.exp: Add additional_flags=-Wl,--build-id.
Break i386-dis-evex.h into small files such that each file is included
just once.
* i386-dis-evex.h: Break into ...
* i386-dis-evex-len.h: New file.
* i386-dis-evex-mod.h: Likewise.
* i386-dis-evex-prefix.h: Likewise.
* i386-dis-evex-reg.h: Likewise.
* i386-dis-evex-w.h: Likewise.
* i386-dis.c: Include i386-dis-evex-reg.h, i386-dis-evex-prefix.h,
i386-dis-evex.h, i386-dis-evex-len.h, i386-dis-evex-w.h and
i386-dis-evex-mod.h.
This patch removes uses of VEC (dwarf2_section_info_def) in favor of
std::vector<dwarf2_section_info>. The conversion is relatively
straightforward, no function changes are intended.
gdb/ChangeLog:
* dwarf2read.h (dwarf2_section_info_def): Remove.
(DEF_VEC_O (dwarf2_section_info_def)): Remove.
* dwarf2read.c (struct dwo_sections) <types>: Change type to
std::vector<dwarf2_section_info>.
(struct dwo_file) <~dwo_file>: Remove.
(dwarf2_per_objfile::~dwarf2_per_objfile): Don't manually free
types field.
(dwarf2_per_objfile::locate_sections): Adjust to std::vector.
(dwarf2_read_debug_names): Likewise.
(create_debug_types_hash_table): Change parameter type to
array_view, adjust code accordingly.
(dwarf2_locate_dwo_sections): Adjust to std::vector.
(partial_die_info::fixup): Likewise.
(determine_prefix): Likewise.
* dwarf-index-write.c (write_psymtabs_to_index): Adjust.
This removes the manual call to gdb_bfd_ref in favor of gdb_bfd_ref_ptr.
gdb/ChangeLog:
* dwarf2read.c (struct dwo_file) <dbfd>: Change type to
gdb_bfd_ref_ptr.
<~dwo_file>: Remove call to gdb_bfd_unref.
(open_and_init_dwo_file): Move gdb_bfd_ref_ptr into dbfd field. Call
gdb_bfd_ref_ptr::get.
This patch changes dwo_file to be allocated/deallocated with new/delete,
so that we can start using C++ features in it, and in struct
dwo_sections.
The free_dwo_file function becomes the destructor of struct dwo_file
(and will disappear in upcoming patches, which will use gdb_bfd_ref_ptr
for dbfd and an std::vector for sections.types).
gdb/ChangeLog:
* dwarf2read.h (struct dwarf2_per_objfile) <dwo_files>: Change
type to htab_up.
* dwarf2read.c (struct dwo_file): Initialize fields.
<~dwo_file>: New.
(free_dwo_file): Remove, move content to ~dwo_file.
(struct dwo_file_deleter): Remove.
(dwo_file_up>: Remove custom deleter.
(free_dwo_files): Remove.
(dwarf2_per_objfile::~dwarf2_per_objfile): Don't explicitly free
dwo_files.
(process_skeletonless_type_units): Call unique_ptr::get.
(allocate_dwo_file_hash_table): Add deleter to created hash
table. Change return type to htab_up.
(lookup_dwo_file_slot): Don't memset dwo_file, call
unique_ptr::get.
(create_dwo_unit_in_dwp_v1): Allocate dwo_file with new.
(create_dwo_unit_in_dwp_v2): Likewise.
(open_and_init_dwo_file): Likewise.
(free_dwo_file_from_slot): Remove.
Use bool instead of char where applicable in dwarf2_section_info.
No functional changes intended.
gdb/ChangeLog:
* dwarf2read.h (struct dwarf2_section_info) <readin,
is_virtual>: Change type to bool.
* dwarf2read.c (dwarf2_read_section, create_dwp_v2_section): Use
true instead of 1.
When testing gdb with board cc-with-gdb-index, we run into:
...
FAIL: gdb.ada/ptype_union.exp: ptype global
FAIL: gdb.ada/ptype_union.exp: print global
...
The index is not supported for Ada (PR24713), and cc-with-gdb-index does not
add an index for Ada test-cases. However, this test-case compiles C sources,
for which cc-with-gdb-index does add an index. In gdb we load the executable
containing the index and set the language to Ada, resulting in gdb trying to
handle something that is not supported.
Fix the fail by marking this unsupported.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-21 Tom de Vries <tdevries@suse.de>
PR testsuite/24518
PR ada/24713
* gdb.ada/ptype_union.exp: Mark as unsupported if executable contains
index.
This commit fixes two paths in update-gnulib.sh that weren't updated
when gnulib was moved to toplevel.
gnulib/ChangeLog:
* update-gnulib.sh: Adjust paths.
ctf_open (or, rather, ctf_fdopen, which underlies it) has several
endianness problems, even though it was written after the
endian-swapping code was implemented, so should have been endian-aware.
Even though the comment right above the relevant check says that it wil
check for CTF magic in any endianness, it only checks in the native
endianness, so opening raw LE CTF files on BE, or vice-versa, will fail.
It also checks the CTF version by hand, without ever endianness-swapping
the header, so that too will fail, and is entirely redundant because
ctf_simple_open does the job properly in any case. We have a similar
problem in the next if block, which checks for raw CTF archives: we are
checking in the native endianness while we should be doing a le64toh()
on it to check in little-endian form only: so opening CTF archives
created on the local machine will fail if the local machine is
big-endian.
Adding insult to injury, if ctf_simple_open then fails, we go on and try
to turn it into a single-element CTF archive regardless, throwing the
error away. Since this involves dereferencing null pointers it is not
likely to work very well.
libctf/
* ctf-open-bfd.c: Add swap.h and ctf-endian.h.
(ctf_fdopen): Check for endian-swapped raw CTF magic, and
little-endian CTF archive magic. Do not check the CTF version:
ctf_simple_open does that in endian-safe ways. Do not dereference
null pointers on open failure.
Testing of the first code to generate CTF_K_SLICEs on big-endian
revealed a bunch of new problems in this area. Most importantly, the
trick we did earlier to avoid wasting two bytes on padding in the
ctf_slice_t is best avoided: because it leads to the whole file after
that point no longer being naturally aligned, all multibyte accesses
from then on must use memmove() to avoid unaligned access on platforms
where that is fatal. In future, this is planned, but for now we are
still doing direct access in many places, so we must revert to making
ctf_slice_t properly aligned for storage in an array.
Rather than wasting bytes on padding, we boost the size of cts_offset
and cts_bits. This is still a waste of space (we cannot have offsets or
bits in bitfields > 256) but it cannot be avoided for now, and slices
are not so common that this will be a serious problem.
A possibly-worse endianness problem fixed at the same time involves
a codepath used only for foreign-endian, uncompressed CTF files, where
we were not copying the actual CTF data into the buffer, leading to
libctf reading only zeroes (or, possibly, uninitialized garbage).
Finally, when we read in a CTF file, we copy the header and work from
the copy. We were flipping the endianness of the header copy, and of
the body of the file buffer, but not of the header in the file buffer
itself: so if we write the file back out again we end up with an
unreadable frankenfile with header and body of different endiannesses.
Fix by flipping both copies of the header.
include/
* ctf.h (ctf_slice_t): Make cts_offset and cts_bits unsigned
short, so following structures are properly aligned.
libctf/
* ctf-open.c (get_vbytes_common): Return the new slice size.
(ctf_bufopen): Flip the endianness of the CTF-section header copy.
Remember to copy in the CTF data when opening an uncompressed
foreign-endian CTF file. Prune useless variable manipulation.
If we see a CTF type with a kind we do not recognize in its ctt_info
during opening, we cannot skip it and continue opening the file: if the
type kind is unknown, we do not know how long its vlen is, and we cannot
have skipped past it: so if we continue reading we will almost certainly
read in part of the vlen as if it were a new ctf_type_t.
Avoid this trouble by considering unknown type kinds to be a reason to
return ECTF_CORRUPT, just like everything else that reads in type kinds
does.
libctf/
* ctf-open.c (ctf_types): Fail when unidentified type kinds are
seen.
This is an essential first piece of info needed to debug both libctf
writing and reading problems, and we weren't recording it anywhere!
(This is a short-term fix: fairly soon, we will record all of this in a
form that outlives ctf_bufopen, and then ctf_dump() will be able to dump
it like it can everything else.)
libctf/
* ctf-open.c (ctf_bufopen): Dump header offsets into the debugging
output.
This allocator has the ostensible benefit that it lets us mprotect() the
memory used for CTF storage: but in exchange for this it adds
considerable complexity, since we have to track allocation sizes
ourselves for use at freeing time, note whether the data we are storing
was ctf_data_alloc()ed or not so we know if we can safely mprotect()
it... and while the mprotect()ing has found few bugs, it *has* been the
cause of more than one due to errors in all this tracking leading to us
mprotect()ing bits of the heap and stuff like that.
We are about to start composing CTF buffers from pieces so that we can
do usage-based optimizations on the strtab. This means we need
realloc(), which needs nonportable mremap() and *more* tracking of the
*original* allocation size, and the complexity and bureaucracy of all of
this is just too high for its negligible benefits.
Drop the whole thing and just use malloc() like everyone else. It knows
better than we do when it is safe to use mmap() under the covers,
anyway.
While we're at it, don't leak the entire buffer if ctf_compress_write()
fails to compress it.
libctf/
* ctf-subr.c (_PAGESIZE): Remove.
(ctf_data_alloc): Likewise.
(ctf_data_free): Likewise.
(ctf_data_protect): Likewise.
* ctf-impl.h: Remove declarations.
* ctf-create.c (ctf_update): No longer call ctf_data_protect: use
ctf_free, not ctf_data_free.
(ctf_compress_write): Use ctf_data_alloc, not ctf_alloc. Free
the buffer again on compression error.
* ctf-open.c (ctf_set_base): No longer track the size: call
ctf_free, not ctf_data_free.
(upgrade_types): Likewise. Call ctf_alloc, not ctf_data_alloc.
(ctf_bufopen): Likewise. No longer call ctf_data_protect.
We were missing several cases where dynhash insertion might fail, likely
due to OOM but possibly for other reasons. Pass the errors on.
libctf/
* ctf-create.c (ctf_dtd_insert): Pass on error returns from
ctf_dynhash_insert.
(ctf_dvd_insert): Likewise.
(ctf_add_generic): Likewise.
(ctf_add_variable): Likewise.
* ctf-impl.h: Adjust declarations.
The testcase in the PR had a e_shstrndx section of type SHT_GROUP.
hdr->contents were initialized by setup_group rather than being read
from the file, thus last byte was not zero and string dereference ran
off the end of the buffer.
PR 24689
* elfcode.h (elf_object_p): Check type of e_shstrndx section.
When building gdb on s390x with -m31, we run into this error:
...
gdb/gdbserver/linux-s390-ipa.c: \
In function 'const target_desc* get_ipa_tdesc(int)':
gdb/gdbserver/linux-s390-ipa.c:371:18: error: 's390_te_ft_collect_regmap' \
was not declared in this scope
SET_REGMAP(s390_te_ft_collect_regmap, 0);
The offending line is part of this code snippet:
...
case S390_TDESC_GS:
SET_REGMAP(s390_te_ft_collect_regmap, 0);
return tdesc_s390_gs_linux64;
...
introduced in commit ce29f8439f "S390: Make IPA recognize tdescs with guarded
storage".
The snippet is part of an #ifdef __s390x__ construct, in the false branch, and
in the true branch we find a snippet introduced by the same commit:
...
case S390_TDESC_GS:
SET_REGMAP(s390x_te_ft_collect_regmap, 0);
return tdesc_s390x_gs_linux64;
...
which is paired with a comment update for s390x_te_ft_collect_regmap:
...
-/* Used for s390x-te-linux64, s390x-tevx-linux64. */
+/* Used for s390x-te-linux64, s390x-tevx-linux64, and
+ s390x-gs-linux64. */
static const int s390x_te_ft_collect_regmap[] = {
...
A similar comment update is added in the same commit for
s390_te_linux64_ft_collect_regmap:
...
-/* Used for s390-te-linux64, s390-tevx-linux64. */
+/* Used for s390-te-linux64, s390-tevx-linux64, and s390-gs-linux64. */
static const int s390_te_linux64_ft_collect_regmap[] = {
...
but not paired with any update.
Fix the build breaker by making the offending SET_REGMAP use the regmap
indicated by the comment.
...
- SET_REGMAP(s390_te_ft_collect_regmap, 0);
+ SET_REGMAP(s390_te_linux64_ft_collect_regmap, 0);
...
Build on s390x-linux with -m31.
gdb/gdbserver/ChangeLog:
2019-06-20 Tom de Vries <tdevries@suse.de>
* linux-s390-ipa.c (get_ipa_tdesc)[!__s390x__]: Use
s390_te_linux64_ft_collect_regmap for S390_TDESC_GS.
I noticed that tui_init_content_element is declared but never defined.
This removes the declaration. Tested by rebuilding. (I should have
merged this with the previous patch but I had forgotten that I found
two of these.)
gdb/ChangeLog
2019-06-19 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (tui_init_content_element): Don't declare.
I noticed that tui_init_win_info is declared but never defined. This
removes the declaration. Tested by rebuilding.
gdb/ChangeLog
2019-06-19 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (tui_init_win_info): Don't declare.
Building gdb with clang, I run into:
...
src/gdb/gdbserver/linux-low.c:6190:41: error: comparison of unsigned \
expression < 0 is always false [-Werror,-Wtautological-compare]
if (debug_write ("sigchld_handler\n",
sizeof ("sigchld_handler\n") - 1) < 0)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~
...
This regression is introduced by commit a7e559cc08 "gdbserver: Ensure all
debug output uses debug functions", which replaces calls to write with result
type ssize_t with calls to debug_write with result type size_t.
Fix this by making debug_write return ssize_t.
Build and reg-tested on x86_64-linux.
gdb/gdbserver/ChangeLog:
2019-06-19 Tom de Vries <tdevries@suse.de>
* debug.h (debug_write): Change return type to ssize_t.
* debug.c (debug_write): Same.
When compiling with gcc 4.8, we run into:
...
/usr/include/c++/4.8/bits/unordered_map.h💯18: required from \
‘class std::unordered_map<sect_offset, std::vector<sect_offset> >’
src/gdb/dwarf2read.h:260:5: required from here
/usr/include/c++/4.8/bits/hashtable_policy.h:1070:12: error: invalid use of \
incomplete type ‘struct std::hash<sect_offset>’
...
Fix this by setting the Hash template parameter of the unordered_map to
gdb::hash_enum<sect_offset>, rather than using the default
std::hash<sect_offset>.
Build and reg-tested on x86_64-linux with gcc 4.8.
gdb/ChangeLog:
2019-06-19 Tom de Vries <tdevries@suse.de>
* dwarf2read.h (abstract_to_concrete): Change type to
std::unordered_map<sect_offset, std::vector<sect_offset>,
gdb::hash_enum<sect_offset>>.
Pedro pointed out that the new length_cond.exp test did not have an
intro comment. This adds one.
gdb/testsuite/ChangeLog
2019-06-19 Tom Tromey <tromey@adacore.com>
* gdb.ada/length_cond.exp: Add intro comment.
gdb could crash when setting a breakpoint condition on a breakpoint
when using the Ada language. The problem occurred because the
ada_evaluate_subexp would try to evaluate the array to compute its
attributes, but evaluating can't really be done at this time.
This patch fixes the problem by arranging not to try to evaluate in
EVAL_AVOID_SIDE_EFFECTS mode when computing an attribute.
Tested on x86-64 Fedora 29. Because this is Ada-specific, and because
Joel approved it internally, I am checking it in.
gdb/ChangeLog
2019-06-19 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_evaluate_subexp) <case OP_ATR_FIRST>: Handle
EVAL_AVOID_SIDE_EFFECTS specially.
gdb/testsuite/ChangeLog
2019-06-19 Tom Tromey <tromey@adacore.com>
* gdb.ada/length_cond.exp: New file.
* gdb.ada/length_cond/length_cond.adb: New file.
* gdb.ada/length_cond/pck.adb: New file.
* gdb.ada/length_cond/pck.ads: New file.
It occurred to me that there's no reason to make a new source
highlighter each time gdb needs to highlight some source code.
Instead, a single one can be created and then simply reused each time.
This patch implements this idea. Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-19 Tom Tromey <tromey@adacore.com>
* source-cache.c (highlighter): New global.
(source_cache::get_source_lines): Create a highlighter on demand.
