aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-06-23PR24704, Internal error building skiboot for powerpc64-linux-gnuAlan Modra5-23/+38
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.
2019-06-23PR24689 again, string table corruptionAlan Modra2-4/+5
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.
2019-06-23Automatic date update in version.inGDB Administrator1-1/+1
2019-06-22Remove tui_first_data_element_no_in_lineTom Tromey3-18/+6
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.
2019-06-22Remove two unused functions from the TUITom Tromey3-79/+6
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.
2019-06-22[gdb] Fix s390x -m31 buildTom de Vries2-18/+30
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'.
2019-06-22Automatic date update in version.inGDB Administrator1-1/+1
2019-06-21[gdb/testsuite] Compile index-cache.c with -Wl,--build-idTom de Vries2-1/+6
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.
2019-06-21i386: Break i386-dis-evex.h into small filesH.J. Lu8-3486/+3472
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.
2019-06-21dwarf2read: Get rid of VEC (dwarf2_section_info_def)Simon Marchi4-39/+32
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.
2019-06-21dwarf2read: Make dwo_file::dbfd a gdb_bfd_ref_ptrSimon Marchi2-6/+12
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.
2019-06-21dwarf2read: C++ify dwo_fileSimon Marchi3-75/+61
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.
2019-06-21dwarf2read: Use bool for dwarf2_section_info fieldsSimon Marchi3-4/+11
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.
2019-06-21[gdb/testsuite] Mark ptype_union.exp as unsupported for cc-with-gdb-indexTom de Vries2-0/+12
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.
2019-06-21Add gnulib to gdb release tarballAndreas Schwab2-1/+5
* src-release.sh (GDB_SUPPORT_DIRS): Add gnulib.
2019-06-21Fix gnulib/update-gnulib.shGary Benson2-4/+8
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.
2019-06-21libctf: fix ctf_open endianness problems with raw CTF filesNick Alcock2-9/+22
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.
2019-06-21libctf: endianness fixesNick Alcock4-10/+30
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.
2019-06-21libctf: unidentified type kinds on open are a sign of file corruptionNick Alcock2-0/+9
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.
2019-06-21libctf: dump header offsets into the debugging outputNick Alcock2-0/+8
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.
2019-06-21libctf: drop mmap()-based CTF data allocatorNick Alcock5-89/+32
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.
2019-06-21libctf: handle errors on dynhash insertion betterNick Alcock3-12/+35
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.
2019-06-21PR24689, string table corruptionAlan Modra2-1/+7
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.
2019-06-21Automatic date update in version.inGDB Administrator1-1/+1
2019-06-20[gdbserver] Fix s390x -m31 gdbserver buildTom de Vries2-1/+6
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.
2019-06-19Don't declare tui_init_content_elementTom Tromey2-2/+4
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.
2019-06-19Don't declare tui_init_win_infoTom Tromey2-1/+4
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.
2019-06-20Automatic date update in version.inGDB Administrator1-1/+1
2019-06-19i386: Check vector length for EVEX broadcast instructionsH.J. Lu8-14/+133
Since not all vector lengths are supported by EVEX broadcast instructions, decode them only with supported vector lengths. gas/ PR binutils/24700 * testsuite/gas/i386/disassem.s: Add test for vbroadcasti32x8 with invalid vector length. * testsuite/gas/i386/x86-64-disassem.s: Likewise. * testsuite/gas/i386/disassem.d: Updated. * testsuite/gas/i386/x86-64-disassem.d: Likewise. opcodes/ PR binutils/24700 * i386-dis-evex.h (evex_table): Update EVEX_W_0F3819_P_2, EVEX_W_0F381A_P_2, EVEX_W_0F381B_P_2, EVEX_W_0F385A_P_2 and EVEX_W_0F385B_P_2. (evex_len_table): Add EVEX_LEN_0F3819_P_2_W_0, EVEX_LEN_0F3819_P_2_W_1, EVEX_LEN_0F381A_P_2_W_0, EVEX_LEN_0F381A_P_2_W_1, EVEX_LEN_0F381B_P_2_W_0, EVEX_LEN_0F381B_P_2_W_1, EVEX_LEN_0F385A_P_2_W_0, EVEX_LEN_0F385A_P_2_W_1, EVEX_LEN_0F385B_P_2_W_0 and EVEX_LEN_0F385B_P_2_W_1. * i386-dis.c (EVEX_LEN_0F3819_P_2_W_0): New enum. (EVEX_LEN_0F3819_P_2_W_1): Likewise. (EVEX_LEN_0F381A_P_2_W_0): Likewise. (EVEX_LEN_0F381A_P_2_W_1): Likewise. (EVEX_LEN_0F381B_P_2_W_0): Likewise. (EVEX_LEN_0F381B_P_2_W_1): Likewise. (EVEX_LEN_0F385A_P_2_W_0): Likewise. (EVEX_LEN_0F385A_P_2_W_1): Likewise. (EVEX_LEN_0F385B_P_2_W_0): Likewise. (EVEX_LEN_0F385B_P_2_W_1): Likewise.
2019-06-19[gdb] Fix clang buildbreakerTom de Vries3-2/+7
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.
2019-06-19[gdb] Fix build breaker with gcc 4.8Tom de Vries2-1/+9
When compiling with gcc 4.8, we run into: ... /usr/include/c++/4.8/bits/unordered_map.h:100: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>>.
2019-06-19Add intro comment to length_cond.expTom Tromey2-0/+7
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.
2019-06-19Fix crash when setting breakpoint conditionTom Tromey7-7/+159
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.
2019-06-19Instantiate a single source highlighterTom Tromey2-3/+19
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.
2019-06-19PR24697, R_PPC_EMB_SDA21 relocationAlan Modra2-7/+21
PR 24697 * elf32-ppc.c (ppc_elf_relocate_section): Don't read insn for R_PPC_EMB_RELSDA. Mask low bit of R_PPC_EMB_SDA21 r_offset.
2019-06-19PowerPC64 notoc callsAlan Modra2-3/+9
Calls from functions that don't have a valid toc pointer in r2 (these calls are marked with _NOTOC relocs) to functions that require r2 valid must go via the callee global entry point. This patch corrects the condition the linker was using to detect functions that require r2 to be valid. Values of both zero and one in st_other local entry bits mean a function doesn't care about r2. * elf64-ppc.c (ppc64_elf_inline_plt): Correct st_other test for functions that require r2 valid to use local entry. (ppc64_elf_size_stubs, ppc64_elf_relocate_section): Likewise.
2019-06-19Automatic date update in version.inGDB Administrator1-1/+1
2019-06-18gdb: Remove use of deprecated_interactive_hookAndrew Burgess5-10/+8
The deprecated_interactive_hook is not used within GDB. It is used in gdbtk, however this patch removes that use: https://sourceware.org/ml/insight/2019-q2/msg00001.html So I think there is no longer a reason to keep this hook around. This patch removes it. There should be no user visible changes after this commit. gdb/ChangeLog: * defs.h (deprecated_interactive_hook): Delete declaration. * interps.c (clear_interpreter_hooks): Remove use of deprecated_interactive_hook. * top.c (deprecated_interactive_hook): Delete definition. * utils.c (maybe_quit): Remove use of deprecated_interactive_hook.
2019-06-18[gdb/testsuite] Use -fuse-ld=gold in fission.expTom de Vries2-1/+6
The target board fission.exp requires the gold linker (because it supports --gdb-index). When running the target board on a system where the default linker is not gold, most tests will fail to compile. Fix this by adding "-fuse-ld=gold" ( supported in gcc since version 4.8). gdb/testsuite/ChangeLog: 2019-06-18 Tom de Vries <tdevries@suse.de> * boards/fission.exp (debug_flags): Add "-fuse-ld=gold".
2019-06-18[gdb] Fix abstract_to_concrete typeTom de Vries3-5/+19
The test-case varval.exp fails here: ... FAIL: gdb.dwarf2/varval.exp: print varval2 ... with boards readnow/cc-with-gdb-index/cc-with-debug-names, as well as if gdb is build with -fsanitize=address -lasan. The problem is that the abstract_to_concrete map in which we track the association of abstract to concrete DIEs (for DW_OP_GNU_variable_value support) has type std::unordered_map<die_info_ptr, std::vector<die_info_ptr>>, and the die_info_ptrs that we register in the map may be invalid by the time that we start to lookup DIEs in the map. Fix this by using the sect_offset instead to identify the DIEs in the map. Build and tested on x86_64-linux. gdb/ChangeLog: 2019-06-18 Tom de Vries <tdevries@suse.de> PR gdb/24515 * dwarf2read.h (abstract_to_concrete): Change type from std::unordered_map<die_info_ptr, std::vector<die_info_ptr>> to std::unordered_map<sect_offset, std::vector<sect_offset>>. * dwarf2read.c (read_variable): Update. (dwarf2_fetch_die_loc_sect_off): Update.
2019-06-18doc: fix false claim about second argument to gdbSimon Marchi2-9/+16
Section "Invoking GDB" of the manual states that if you try to launch gdb with: gdb program 1234 it will try to attach to the process with id 1234, unless there is a file named 1234 in the current working directory, in which case it will try to open that file as a core. In fact, when the second argument starts with a digit, GDB tries to attach to process 1234 first, before trying to open file 1234 as a core. So that last remark is not true and therefore this patch removes it. The same remark is present in the man page, so it is removed there too. Section "Choosing Files" correctly states: If the second argument begins with a decimal digit, GDB will first attempt to attach to it as a process, and if that fails, attempt to open it as a corefile. so it is unchanged. Finally, the man page has an additional detail compared to section "Invoking GDB", regarding the use of the -p switch, so I added the same detail to the "Invoking GDB" section. gdb/doc/ChangeLog: * gdb.texinfo (Invoking GDB): Remove sentence about how GDB deals with a file that has the same name as the specified pid to attach to. Add example using -p option. (gdb man): Remove same sentence as in previous item.
2019-06-18Add comment to list0.hTom Tromey2-1/+5
Pedro suggested adding a comment to list0.h to explain the control character. Tested on x86-64 Fedora 29. gdb/testsuite/ChangeLog 2019-06-18 Tom Tromey <tromey@adacore.com> * gdb.base/list0.h: Add comment explaining control character.
2019-06-18[gdb/testsuite] Break up long debug_flags line in fission.expTom de Vries2-1/+10
gdb/testsuite/ChangeLog: 2019-06-18 Tom de Vries <tdevries@suse.de> * boards/fission.exp: Break up long debug_flags line.
2019-06-18Automatic date update in version.inGDB Administrator1-1/+1
2019-06-17[gdb] Fix heap-buffer-overflow in child_pathTom de Vries2-1/+7
When compiling gdb with '-lasan -fsanitizer=address' and running tests with: - export ASAN_OPTIONS="detect_leaks=0:alloc_dealloc_mismatch=0", and - a target board using local-board.exp, which sets sysroot to "" we run into a heap-buffer-overflow in child_path for f.i. gdb.arch/amd64-byte: ... ==3997==ERROR: AddressSanitizer: heap-buffer-overflow on address \ 0x60200002abcf at pc 0x5602acdf6872 bp 0x7ffe5237a090 sp 0x7ffe5237a080 READ of size 1 at 0x60200002abcf thread T0 #0 0x5602acdf6871 in child_path(char const*, char const*) \ gdb/common/pathstuff.c:161 #1 0x5602adb06587 in find_separate_debug_file gdb/symfile.c:1483 #2 0x5602adb06f2f in find_separate_debug_file_by_debuglink[abi:cxx11](...) \ gdb/symfile.c:1563 #3 0x5602ad13b743 in elf_symfile_read gdb/elfread.c:1293 #4 0x5602adb01cfa in read_symbols gdb/symfile.c:798 #5 0x5602adb03769 in syms_from_objfile_1 gdb/symfile.c:1000 #6 0x5602adb039d0 in syms_from_objfile gdb/symfile.c:1017 #7 0x5602adb04551 in symbol_file_add_with_addrs gdb/symfile.c:1124 #8 0x5602adb04ebf in symbol_file_add_from_bfd(...) gdb/symfile.c:1204 #9 0x5602ada5a78d in solib_read_symbols(...) gdb/solib.c:695 #10 0x5602ada5bdae in solib_add(char const*, int, int) gdb/solib.c:1004 #11 0x5602ada49bcd in enable_break gdb/solib-svr4.c:2394 #12 0x5602ada4dae9 in svr4_solib_create_inferior_hook gdb/solib-svr4.c:3028 #13 0x5602ada5d4f1 in solib_create_inferior_hook(int) gdb/solib.c:1215 #14 0x5602ad347f66 in post_create_inferior(target_ops*, int) \ gdb/infcmd.c:467 #15 0x5602ad348b3c in run_command_1 gdb/infcmd.c:663 #16 0x5602ad348e55 in run_command gdb/infcmd.c:686 #17 0x5602acd7d32b in do_const_cfunc gdb/cli/cli-decode.c:106 #18 0x5602acd84bfe in cmd_func(cmd_list_element*, char const*, int) \ gdb/cli/cli-decode.c:1892 #19 0x5602adc62a90 in execute_command(char const*, int) gdb/top.c:630 #20 0x5602ad5053e6 in catch_command_errors gdb/main.c:372 #21 0x5602ad507eb1 in captured_main_1 gdb/main.c:1138 #22 0x5602ad5081ec in captured_main gdb/main.c:1163 #23 0x5602ad508281 in gdb_main(captured_main_args*) gdb/main.c:1188 #24 0x5602ac9ddc3a in main gdb/gdb.c:32 #25 0x7f582b56eb96 in __libc_start_main \ (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #26 0x5602ac9dda09 in _start \ (/home/smarchi/build/binutils-gdb/gdb/gdb+0x19a2a09) 0x60200002abcf is located 1 bytes to the left of 1-byte region \ [0x60200002abd0,0x60200002abd1) allocated by thread T0 here: #0 0x7f582e0e4b50 in __interceptor_malloc \ (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50) #1 0x5602acdd3656 in xmalloc gdb/common/common-utils.c:44 #2 0x5602aefe17d1 in xstrdup libiberty/xstrdup.c:34 #3 0x5602acdf61f6 in gdb_realpath(char const*) gdb/common/pathstuff.c:80 #4 0x5602adb06278 in find_separate_debug_file gdb/symfile.c:1444 #5 0x5602adb06f2f in find_separate_debug_file_by_debuglink[abi:cxx11](...) \ gdb/symfile.c:1563 #6 0x5602ad13b743 in elf_symfile_read gdb/elfread.c:1293 #7 0x5602adb01cfa in read_symbols gdb/symfile.c:798 #8 0x5602adb03769 in syms_from_objfile_1 gdb/symfile.c:1000 #9 0x5602adb039d0 in syms_from_objfile gdb/symfile.c:1017 #10 0x5602adb04551 in symbol_file_add_with_addrs gdb/symfile.c:1124 #11 0x5602adb04ebf in symbol_file_add_from_bfd(...) gdb/solib.c:695 #13 0x5602ada5bdae in solib_add(char const*, int, int) gdb/solib.c:1004 #14 0x5602ada49bcd in enable_break gdb/solib-svr4.c:2394 #15 0x5602ada4dae9 in svr4_solib_create_inferior_hook gdb/solib-svr4.c:3028 #16 0x5602ada5d4f1 in solib_create_inferior_hook(int) gdb/solib.c:1215 #17 0x5602ad347f66 in post_create_inferior(target_ops*, int) \ gdb/infcmd.c:467 #18 0x5602ad348b3c in run_command_1 gdb/infcmd.c:663 #19 0x5602ad348e55 in run_command gdb/infcmd.c:686 #20 0x5602acd7d32b in do_const_cfunc gdb/cli/cli-decode.c:106 #21 0x5602acd84bfe in cmd_func(cmd_list_element*, char const*, int) \ gdb/cli/cli-decode.c:1892 #22 0x5602adc62a90 in execute_command(char const*, int) gdb/top.c:630 #23 0x5602ad5053e6 in catch_command_errors gdb/main.c:372 #24 0x5602ad507eb1 in captured_main_1 gdb/main.c:1138 #25 0x5602ad5081ec in captured_main gdb/main.c:1163 #26 0x5602ad508281 in gdb_main(captured_main_args*) gdb/main.c:1188 #27 0x5602ac9ddc3a in main gdb/gdb.c:32 #28 0x7f582b56eb96 in __libc_start_main \ (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) SUMMARY: AddressSanitizer: heap-buffer-overflow gdb/common/pathstuff.c:161 \ in child_path(char const*, char const*) Shadow bytes around the buggy address: 0x0c047fffd520: fa fa fd fd fa fa fd fd fa fa fd fa fa fa fd fa 0x0c047fffd530: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fffd540: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fffd550: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fa 0x0c047fffd560: fa fa fd fa fa fa fd fa fa fa fd fa fa fa 00 00 =>0x0c047fffd570: fa fa 07 fa fa fa 00 fa fa[fa]01 fa fa fa fa fa 0x0c047fffd580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffd590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffd5a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffd5b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffd5c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==3997==ABORTING ... The direct cause is that child_path gets called with parent == "", so this test: ... if (IS_DIR_SEPARATOR (parent[parent_len - 1])) ... accesses parent[-1]. [ There is an open discussion (1) about whether an empty sysroot should indeed be represented internally as "". But this patch focuses on fixing the heap-buffer-overflow without any redesign. ] Fix this by guarding the test with 'parent_len > 0'. Note that the fix makes child_path behave the same for: - parent == "/" && child == "/foo" (returns "foo") - parent == "" and child == "/foo" (returns "foo"). Build and reg-tested on x86_64-linux. (1) https://sourceware.org/ml/gdb-patches/2019-05/msg00193.html gdb/ChangeLog: 2019-06-17 Tom de Vries <tdevries@suse.de> PR gdb/24617 * common/pathstuff.c (child_path): Make sure parent_len > 0 before accessing parent[parent_len - 1].
2019-06-17PR gdb/24364: Don't call dtrace_process_dof with NULL dof.Paul Pluzhnikov2-4/+11
2019-06-17i386: Check vector length for vshufXXX/vinsertXXX/vextractXXXH.J. Lu8-15/+154
Since not all vector lengths are supported by vshufXXX, vinsertXXX and vextractXXX, decode them only with supported vector lengths. gas/ PR binutils/24691 * testsuite/gas/i386/disassem.s: Add test for vshuff32x4 with invalid vector length. * testsuite/gas/i386/x86-64-disassem.s: Likewise. * testsuite/gas/i386/disassem.d: Updated. * testsuite/gas/i386/x86-64-disassem.d: Likewise. opcodes/ PR binutils/24691 * i386-dis-evex.h (evex_table): Update EVEX_W_0F3A23_P_2, EVEX_W_0F3A38_P_2, EVEX_W_0F3A39_P_2, EVEX_W_0F3A3A_P_2, EVEX_W_0F3A3B_P_2 and EVEX_W_0F3A43_P_2. (evex_len_table): Add EVEX_LEN_0F3A23_P_2_W_0, EVEX_LEN_0F3A23_P_2_W_1, EVEX_LEN_0F3A38_P_2_W_0, EVEX_LEN_0F3A38_P_2_W_1, EVEX_LEN_0F3A39_P_2_W_0, EVEX_LEN_0F3A39_P_2_W_1, EVEX_LEN_0F3A3A_P_2_W_0, EVEX_LEN_0F3A3A_P_2_W_1, EVEX_LEN_0F3A3B_P_2_W_0, EVEX_LEN_0F3A3B_P_2_W_1, EVEX_LEN_0F3A43_P_2_W_0 and EVEX_LEN_0F3A43_P_2_W_1. * i386-dis.c (EVEX_LEN_0F3A23_P_2_W_0): New enum. (EVEX_LEN_0F3A23_P_2_W_1): Likewise. (EVEX_LEN_0F3A38_P_2_W_0): Likewise. (EVEX_LEN_0F3A38_P_2_W_1): Likewise. (EVEX_LEN_0F3A39_P_2_W_0): Likewise. (EVEX_LEN_0F3A39_P_2_W_1): Likewise. (EVEX_LEN_0F3A3A_P_2_W_0): Likewise. (EVEX_LEN_0F3A3A_P_2_W_1): Likewise. (EVEX_LEN_0F3A3B_P_2_W_0): Likewise. (EVEX_LEN_0F3A3B_P_2_W_1): Likewise. (EVEX_LEN_0F3A43_P_2_W_0): Likewise. (EVEX_LEN_0F3A43_P_2_W_1): Likewise.
2019-06-17aarch64: remove unnecessary loc_hash_table traversalSzabolcs Nagy2-24/+6
The loc_hash_table should only contain local ifunc symbols. The current code already aborts if there is anything else and for defined ifunc symbols elfNN_aarch64_allocate_dynrelocs is a no-op. bfd/ChangeLog: * elfnn-aarch64.c (elfNN_aarch64_allocate_local_dynrelocs): Remove. (elfNN_aarch64_size_dynamic_sections): Remove loc_hash_table traversal with elfNN_aarch64_allocate_local_dynrelocs.
2019-06-17Automatic date update in version.inGDB Administrator1-1/+1
2019-06-16[gdb/contrib] Fix gdb/contrib/gdb-add-index.sh for dwz-m-ed execsTom de Vries2-47/+96
Atm gdb-add-index.exp fails with target board cc-with-dwz-m. Fix this by updating gdb/contrib/gdb-add-index.sh to handle a dwz-m-ed executable. Tested on x86_64-linux. gdb/ChangeLog: 2019-06-16 Tom de Vries <tdevries@suse.de> PR gdb/24445 * contrib/gdb-add-index.sh: Update to handle dwz-m-ed executable.
generated by cgit v1.1 at 2025-03-07 11:47:07 +0000