aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-08-05Two-level mapusers/simark/regcache-multimap-v2Simon Marchi1-74/+72
Change-Id: I008ddd9a1ef773a8d17e439d24d75d37bbf1a076
2020-08-05gdb: change regcache list to be a mapSimon Marchi3-60/+135
One regcache object is created for each stopped thread and is stored in the regcache::regcaches linked list. Looking up a regcache for a given thread is therefore in O(number of threads). Stopping all threads then becomes O((number of threads) ^ 2). It becomes noticeable when debugging thousands of threads, which is typical with GPU targets. This patch replaces the linked list with an std::unordered_multimap, indexed by (target, ptid). I originally designed it using an std::unordered_map with (target, ptid, arch) as the key, because that's how lookups are done (in get_thread_arch_aspace_regcache). However, the registers_changed_ptid function, also somewhat on the hot path (it is used when resuming threads), needs to delete all regcaches associated to a given (target, ptid) tuple. Using (target, ptid) as a key allows to do this more efficiently (see exception below). If the key of the map was (target, ptid, arch), we'd have to walk all items of the map. The lookup (in get_thread_arch_aspace_regcache), walks over all existing regcaches belonging to this (target, ptid), looking to find the one with the right arch. This is ok, as there will be very few regcaches for a given key (typically one). Lookups become faster when the number of threads grows, compared to the linked list. With a small number of threads, it will probably be a bit slower to do a map lookup than to walk a few linked list nodes, but I don't think it will be noticeable in practice. The function registers_changed_ptid deletes all regcaches related to a given (target, ptid). We must now handle the different cases separately: - NULL target and minus_one_ptid: we delete all the entries - NULL target and non-minus_one_ptid: invalid (checked by assert) - non-NULL target and non-minus_one_ptid: we delete all the entries associated to that tuple, this is done efficiently - a non-NULL target and minus_one_ptid: we delete all the entries associated to that target, whatever the ptid. This is the slightly annoying case, as we can't easily look up all items having this target in their key. I implemented it by walking the list, which is not ideal. The function regcache_thread_ptid_changed is called when a thread changes ptid. It is implemented efficiently using the map, although that's not very important: it is not called often, mostly when creating an inferior, on some specific platforms. Note: In hash_target_ptid, I am combining hash values from std::hash by summing them. I don't think it's ideal, since std::hash is just the identity function for base types. But I don't know what would be better to reduce the change of collisions. If anybody has a better idea, I'd be interested. This patch is a tiny bit from ROCm GDB [1] we would like to merge upstream. Laurent Morichetti gave be these performance numbers: The benchmark used is: time ./gdb --data-directory=data-directory /extra/lmoriche/hip/samples/0_Intro/bit_extract/bit_extract -ex "set pagination off" -ex "set breakpoint pending on" -ex "b bit_extract_kernel if \$_thread == 5" -ex run -ex c -batch It measures the time it takes to continue from a conditional breakpoint with 2048 threads at that breakpoint, one of them reporting the breakpoint. baseline: real 0m10.227s real 0m10.177s real 0m10.362s with patch: real 0m8.356s real 0m8.424s real 0m8.494s [1] https://github.com/ROCm-Developer-Tools/ROCgdb gdb/ChangeLog: * regcache.c (struct target_ptid): New struct. (hash_target_ptid): New struct. (target_ptid_regcache_map): New type. (regcaches): Change type to target_ptid_regcache_map. (get_thread_arch_aspace_regcache): Update to regcaches' new type. (regcache_thread_ptid_changed): Likewise. (registers_changed_ptid): Likewise. (regcaches_size): Likewise. (regcaches_test): Update. (regcache_thread_ptid_changed): Update. * gdbsupport/ptid.h (hash_ptid): New struct. Change-Id: Iabb0a1111707936ca111ddb13f3b09efa83d3402
2020-08-05gdb: pass target to thread_ptid_changed observableSimon Marchi4-7/+144
I noticed what I think is a potential bug. I did not observe it nor was I able to reproduce it using actual debugging. It's quite unlikely, because it involves multi-target and ptid clashes. I added selftests that demonstrate it though. The thread_ptid_changed observer says that thread with OLD_PTID now has NEW_PTID. Now, if for some reason we happen to have two targets defining a thread with OLD_PTID, the observers don't know which thread this is about. regcache::regcache_thread_ptid_changed changes all regcaches with OLD_PTID. If there is a regcache for a thread with ptid OLD_PTID, but that belongs to a different target, this regcache will be erroneously changed. Similarly, infrun_thread_ptid_changed updates inferior_ptid if inferior_ptid matches OLD_PTID. But if inferior_ptid currently refers not to the thread is being changed, but to a thread with the same ptid belonging to a different target, then inferior_ptid will erroneously be changed. This patch adds a `process_stratum_target *` parameter to the `thread_ptid_changed` observable and makes the two observers use it. Tests for both are added, which would fail if the corresponding fix wasn't done. gdb/ChangeLog: * observable.h (thread_ptid_changed): Add parameter `process_stratum_target *`. * infrun.c (infrun_thread_ptid_changed): Add parameter `process_stratum_target *` and use it. (selftests): New namespace. (infrun_thread_ptid_changed): New function. (_initialize_infrun): Register selftest. * regcache.c (regcache_thread_ptid_changed): Add parameter `process_stratum_target *` and use it. (regcache_thread_ptid_changed): New function. (_initialize_regcache): Register selftest. * thread.c (thread_change_ptid): Pass target to thread_ptid_changed observable. Change-Id: I0599e61224b6d154a7b55088a894cb88298c3c71
2020-08-05gdb: move regcache::regcaches to regcache.cSimon Marchi5-50/+35
I don't really understand why `regcache_thread_ptid_changed` is a static method of `struct regcache` instead of being a static free function in regcache.c. And I don't understand why `current_regcache` is a static member of `struct regcache` instead of being a static global in regcache.c. It's not wrong per-se, but there's no other place where we do it like this in GDB (as far as I remember) and it just exposes things unnecessarily in the .h. Move them to be just static in regcache.c. As a result, registers_changed_ptid doesn't need to be friend of the regcache class anymore. Removing the include of forward_list in regcache.h showed that we were missing an include for it in dwarf2/index-write.c, record-btrace.c and sparc64-tdep.c. gdb/ChangeLog: * regcache.h (class regcache): Remove friend registers_changed_ptid. <regcache_thread_ptid_changed>: Remove. <regcaches>: Remove. * regcache.c (regcache::regcaches): Rename to... (regcaches): ... this. Make static. (get_thread_arch_aspace_regcache): Update. (regcache::regcache_thread_ptid_changed): Rename to... (regcache_thread_ptid_changed): ... this. Update. (class regcache_access): Remove. (regcaches_test): Update. (_initialize_regcache): Update. * sparc64-tdep.c, dwarf2/index-write.c, record-btrace.c: Include <forward_list>. Change-Id: Iabc25759848010cfbb7ee7e27f60eaca17d61c12
2020-08-05gdb: rename regcache::current_regcache to regcache::regcachesSimon Marchi2-32/+30
The name `current_regcache` for the list of currently-existing regcaches sounds wrong. The name is singular, but it holds multiple regcaches, so it could at least be `current_regcaches`. But in other places in GDB, "current" usually means "the object we are working with right now". For example, we swap the "current thread" when we want to operate on a given thread. This is not the case here, this variable just holds all regcaches that exist at any given time, not "the regcache we are working with right now". So, I think calling it `regcaches` is better. I also considered `regcache_list`, but a subsequent patch will make it a map and not a list, so it would sound wrong again. `regcaches` sounds right for any collection of regcache, whatever the type. Rename a few other things that were related to this `current_regcache` field. Note that there is a `get_current_regcache` function, which returns the regcache of the current thread. That one is fine, because it returns the regcache for the current thread. gdb/ChangeLog: * regcache.h (class regcache) <current_regcache>: Rename to... <regcaches>: ... this. Move doc here. * regcache.c (regcache::current_regcache) Rename to... (regcache::regcaches): ... this. Move doc to header. (get_thread_arch_aspace_regcache): Update. (regcache::regcache_thread_ptid_changed): Update. (registers_changed_ptid): Update. (class regcache_access) <current_regcache_size>: Rename to... <regcaches_size>: ... this. (current_regcache_test): Rename to... (regcaches_test): ... this. (_initialize_regcache): Update. Change-Id: I87de67154f5fe17a1f6aee7c4f2036647ee27b99
2020-08-05Fix variant part regressions with older Rust compilerTom Tromey2-9/+30
Older Rust compilers used special field names, rather than DWARF features, to express the variant parts of Rust enums. This is handled in gdb through a quirk recognizer that rewrites the types. Tom de Vries pointed out in PR rust/26197 that the variant part rewrite regressed this code. This patch fixes the problems: * Univariant enums were not handled properly. Now we simply call alloc_rust_variant for these as well. * There was an off-by-one error in the handling of ordinary enums. * Ordinary enums should have the size of their member types reset to match the size of the enclosing enum. (It's not clear to me if this is truly necessary, but it placates a test, and this is just legacy handling in any case.) Tested with Rust 1.12.0, 1.14.0, 1.19.0, 1.36.0, and 1.45.0 on x86-64 Fedora 32. There were some unrelated failures with 1.14.0 and 1.19,0; but considering that these are fairly old releases, I don't plan to look into them unless someone complains. Note that this patch will not fix all the issues in the PR. In that PR, Tom is using a somewhat unusual build of Rust -- in particular it uses an older (pre-DWARF variant part) LLVM with a newer Rust. I believe this compiler doesn't correctly implement the old-style name fallback; the details are in the bug. gdb/ChangeLog 2020-08-05 Tom Tromey <tromey@adacore.com> PR rust/26197: * dwarf2/read.c (alloc_rust_variant): Handle univariant case. (quirk_rust_enum): Call alloc_rust_variant for univariant case. Fix off-by-one and type size errors in ordinary case.
2020-08-05MSP430: sim: Fix incorrect simulation of unsigned widening multiplyJozef Lawrynowicz5-12/+90
Operand sizes used for simulation of MSP430 hardware multiply operations are not aligned with the sizes used on the target, resulting in the simulator storing signed operands with too much precision. Additionally, simulation of unsigned multiplication is missing explicit casts to prevent any implicit sign extension. gcc.c-torture/execute/pr91450-1.c uses unsigned widening multiplication of 32-bit operands -4 and 2, to produce a 64-bit result: 0xffff fffc * 0x2 = 0x1 ffff fff8 If -4 is stored in 64-bit precision, then the multiplication is essentially signed and the result is -8 in 64-bit precision (0xffff ffff ffff fffc), which is not correct. sim/msp430/ChangeLog: * msp430-sim.c (put_op): For unsigned multiplication, explicitly cast operands to the unsigned type before multiplying. * msp430-sim.h (struct msp430_cpu_state): Fix types used to store hwmult operands. sim/testsuite/sim/msp430/ChangeLog: * mpyull_hwmult.s: New test.
2020-08-05[gdb] Fix prop->const_val uses in gdbtypes.cTom de Vries2-2/+7
After commit 66d6346b25 "gdb: remove TYPE_DYN_PROP_ADDR", I run into: ... FAIL: gdb.fortran/class-allocatable-array.exp: print this%_data%b ... (and 185 more FAILs, all for fortran test-cases). The commit replaces "!x" by "x != 0". Fix this by using "x == 0" instead. Build and tested on x86_64-linux. gdb/ChangeLog: 2020-08-05 Tom de Vries <tdevries@suse.de> * gdbtypes.c (type_not_allocated, type_not_associated): Use "prop->const_val () == 0" instead of "prop->const_val () != 0".
2020-08-05Revert "PR26337, Malloc size error in objdump"Alan Modra2-3/+9
This reverts commit 0b97e818464a42305c8243a980a5c13967554fd9.
2020-08-05PR26337, Malloc size error in objdumpAlan Modra2-4/+9
A malloc failure triggered by a fuzzed object file isn't a real problem unless objdump doesn't exit cleanly after the failure, which it does. However we have bfd_malloc_and_get_section to sanity check size of uncompressed sections before allocating memory. Use it. PR 26337 * objdump.c (load_specific_debug_section): Don't malloc space for section contents, use bfd_malloc_and_get_section.
2020-08-05Automatic date update in version.inGDB Administrator1-1/+1
2020-08-04Z8k: fix sout/soudb opcodes with direct addressChristian Groessler5-8/+20
Problem found by Tadashi G. Takaoka. 2020-08-04 Christian Groessler <chris@groessler.org> Tadashi G. Takaoka <tadashi.g.takaoka@gmail.com> * z8kgen.c (opt): Fix "sout imm16,rs" and "soutb imm16,rbs" opcodes (special "out" to absolute address). * z8k-opc.h: Regenerate. 2020-08-04 Christian Groessler <chris@groessler.org> * gas/testsuite/gas/z8k/inout.d: Adapt to correct encoding of "sout/soutb #imm,reg"
2020-08-04gdb: use bool in frame codeSimon Marchi4-143/+182
Change instances of int variables and return values used as boolean values to use the bool type. Shorten the comments of a few functions, because I think they go a bit too much in implementation details, which appear out of date anyway. Make other misc changes to the functions that are already being changed, such as using nullptr instead of NULL, dropping `struct` keywords and declaring variables when first used. gdb/ChangeLog: * frame.h (frame_id_p): Return bool. (frame_id_artificial_p): Return bool. (frame_id_eq): Return bool. (has_stack_frames): Return bool. (get_selected_frame): Fix typo in comment. (get_frame_pc_if_available): Return bool. (get_frame_address_in_block_if_available): Return bool. (get_frame_func_if_available): Return bool. (read_frame_register_unsigned): Return bool. (get_frame_register_bytes): Return bool. (safe_frame_unwind_memory): Return bool. (deprecated_frame_register_read): Return bool. (frame_unwinder_is): Return bool. * frame.c (struct frame_info) <prev_arch::p>: Change type to bool. <this_id::p>: Likewise. <prev_p>: Likewise. (frame_stash_add): Return bool. (get_frame_id): Use bool. (frame_id_build_special) Use bool. (frame_id_build_unavailable_stack): Use bool. (frame_id_build): Use bool. (frame_id_p): Return bool, use true/false instead of 1/0. (frame_id_artificial_p): Likewise. (frame_id_eq): Likewise. (frame_id_inner): Likewise. (get_frame_func_if_available): Likewise. (read_frame_register_unsigned): Likewise. (deprecated_frame_register_read): Likewise. (get_frame_register_bytes): Likewise. (has_stack_frames): Likewise. (inside_main_func): Likewise. (inside_entry_func): Likewise. (get_frame_pc_if_available): Likewise. (get_frame_address_in_block_if_available): Likewise. (frame_unwinder_is): Likewise. (safe_frame_unwind_memory): Likewise. (frame_unwind_arch): Likewise. Change-Id: I6121fa56739b688be79d73d087d76b268ba5a46a
2020-08-04gdb: change frame_info::prev_func::p type to cached_copy_statusSimon Marchi2-8/+18
One might think that variable `frame_info::prev_func::p` is a simple true/false value, but that's not the case, it can also have the value -1 to mean "unavaiable". Change it to use the `cached_copy_status` enum, which seems designed exactly for this purpose. Rename to `status` to be consistent with `prev_pc::status` (and be cause `p` means `predicate`, which implies boolean, which this is not). gdb/ChangeLog: * frame.c (frame_info) <prev_func> <p>: Rename to status, change type to cached_copy_status. (fprintf_frame): Adjust. (get_frame_func_if_available): Adjust. (frame_cleanup_after_sniffer): Adjust. Change-Id: I50c6ebef6c0acb076e25c741f7f417bfd101d953
2020-08-04Update email address in MAINTAINERSMark Wielaard2-1/+5
gdb/ChangeLog: * MAINTAINERS (Write After Approval): Update email address.
2020-08-04gdb: remove TYPE_DYN_PROP_ADDRSimon Marchi3-6/+7
Remove TYPE_DYN_PROP_ADDR, replacing its uses with calling dynamic_prop::const_val directly. gdb/ChangeLog: * gdbtypes.h (TYPE_DYN_PROP_ADDR): Remove, replace uses with dynamic_prop::const_val. Change-Id: Ie99b9cd9a0627488c1c69a75e57f020d34e392af
2020-08-04gdb: remove TYPE_DYN_PROP_KINDSimon Marchi4-9/+12
Replace uses with calling the dynamic_prop::kind method directly. gdb/ChangeLog: * gdbtypes.h (TYPE_DYN_PROP_KIND): Remove, replace uses with dynamic_prop::kind. Change-Id: I78a3e2890f0b3e3950e9a19ad657b976cbb9610b
2020-08-04gdb: remove TYPE_DYN_PROP_BATONSimon Marchi2-2/+4
This macro is now unused. gdb/ChangeLog: * gdbtypes.h (TYPE_DYN_PROP_BATON): Remove. Change-Id: I6daead794f7ecb516cc59f9e05262c894515fad3
2020-08-04sim: generated files for the eBPF simulatorJose E. Marchesi14-0/+9943
This patch adds the CGEN generated files for the eBPF simulator. sim/ChangeLog: 2020-08-04 Jose E. Marchesi <jose.marchesi@oracle.com> David Faust <david.faust@oracle.com> * bpf/arch.c: Likewise. * bpf/arch.h: Likewise. * bpf/cpu.c: Likewise. * bpf/cpu.h: Likewise. * bpf/cpuall.h: Likewise. * bpf/decode-be.c: Likewise. * bpf/decode-be.h: Likewise. * bpf/decode-le.c: Likewise. * bpf/decode-le.h: Likewise. * bpf/defs-be.h: Likewise. * bpf/defs-le.h: Likewise. * bpf/sem-be.c: Likewise. * bpf/sem-le.c: Likewise.
2020-08-04sim: eBPF simulatorJose E. Marchesi36-0/+18708
This patch introduces the basics of an instruction-simulator for eBPF. The simulator is based on CGEN. gdb/ChangeLog: 2020-08-04 Jose E. Marchesi <jose.marchesi@oracle.com> * configure.tgt: Set gdb_sim for bpf-*-* targets. sim/ChangeLog: 2020-08-04 Jose E. Marchesi <jose.marchesi@oracle.com> David Faust <david.faust@oracle.com> * configure.tgt (sim_arch): Add entry for bpf-*-*. * configure: Regenerate. * MAINTAINERS: Add maintainer for the BPF simulator. * bpf/Makefile.in: New file. * bpf/bpf-helpers.c: Likewise. * bpf/bpf-helpers.def: Likewise. * bpf/bpf-helpers.h: Likewise. * bpf/bpf-sim.h: Likewise. * bpf/bpf.c: Likewise. * bpf/config.in: Likewise. * bpf/configure.ac: Likewise. * bpf/decode.h: Likewise. * bpf/eng.h: Likewise. * bpf/mloop.in: Likewise. * bpf/sim-if.c: Likewise. * bpf/sim-main.h: Likewise. * bpf/traps.c: Likewise. * bpf/configure: Generate. * bpf/aclocal.m4: Likewise. sim/testsuite/ChangeLog: 2020-08-04 David Faust <david.faust@oracle.com> Jose E. Marchesi <jose.marchesi@oracle.com> * configure: Regenerate. * sim/bpf/allinsn.exp: New file. * sim/bpf/alu.s: Likewise. * sim/bpf/alu32.s: Likewise. * sim/bpf/endbe.s: Likewise. * sim/bpf/endle.s: Likewise. * sim/bpf/jmp.s: Likewise. * sim/bpf/jmp32.s: Likewise. * sim/bpf/ldabs.s: Likewise. * sim/bpf/mem.s: Likewise. * sim/bpf/mov.s: Likewise. * sim/bpf/testutils.inc: Likewise. * sim/bpf/xadd.s: Likewise.
2020-08-04gdb: support for eBPFJose E. Marchesi8-0/+434
This patch adds basic support for the eBPF target: tdep and build machinery. The accompanying simulator is introduced in subsequent patches. gdb/ChangeLog: 2020-08-04 Weimin Pan <weimin.pan@oracle.com> Jose E. Marchesi <jose.marchesi@oracle.com> * configure.tgt: Add entry for bpf-*-*. * Makefile.in (ALL_TARGET_OBS): Add bpf-tdep.o (ALLDEPFILES): Add bpf-tdep.c. * bpf-tdep.c: New file. * MAINTAINERS: Add bpf target and maintainer. gdb/doc/ChangeLog: 2020-08-04 Jose E. Marchesi <jose.marchesi@oracle.com> * gdb.texinfo (Contributors): Add information for the eBPF support. (BPF): New section.
2020-08-04gdb/testsuite: Use 'array unset' instead of just 'unset'Andrew Burgess2-1/+6
In the check-test-names.exp library 'unset' was being used to unset an array variable. Though this seems to work fine on tcl 8.6, it was discovered on a CentOS 7.8.2003 machine, running tcl 8.5, that this doesn't work and 'array unset' should be used instead. Using 'array unset' should work fine for newer and older versions of tcl (since 8.3, releases ~2000). gdb/testsuite/ChangeLog: * lib/check-test-names.exp (do_reset_vars): Use 'array unset' to unset the array variable.
2020-08-04gas/NEWS: Mention {disp16} pseudo prefixH.J. Lu2-0/+6
* NEWS: Mention {disp16} pseudo prefix.
2020-08-04gas: Revert an accidental change in x86-64-pseudos.dH.J. Lu2-1/+6
Revert an accidental change in commit 41eb8e88859b297f59f4d093aab9306d4b7057d9 Author: H.J. Lu <hjl.tools@gmail.com> Date: Thu Jul 30 16:13:02 2020 -0700 x86: Add {disp16} pseudo prefix @@ -304,7 +308,7 @@ Disassembly of section .text: +[a-f0-9]+: 40 d3 e0 rex shl %cl,%eax +[a-f0-9]+: 40 a0 01 00 00 00 00 00 00 00 rex movabs 0x1,%al +[a-f0-9]+: 40 38 ca rex cmp %cl,%dl - +[a-f0-9]+: 40 b3 01 rex mov \$(0x)?1,%bl + +[a-f0-9]+: 40 b3 01 rex mov \$(0x)1,%bl +[a-f0-9]+: f2 40 0f 38 f0 c1 rex crc32 %cl,%eax +[a-f0-9]+: 40 89 c3 rex mov %eax,%ebx +[a-f0-9]+: 41 89 c6 mov %eax,%r14d PR gas/26305 * testsuite/gas/i386/x86-64-pseudos.d: Revert an accidental change.
2020-08-04gas: Use udata for DW_AT_high_pc when emitting DWARF4Mark Wielaard4-4/+16
For DWARF4 DW_AT_high_pc can be expressed as constant offset from DW_AT_low_pc which saves a relocation. Use DW_FORM_udate (uleb128) to keep the constant value as small as possible. gas/ChangeLog: * dwarf2dbg.c (out_debug_abbrev): When DWARF2_VERSION >= 4, use DW_FORM_udata for DW_AT_high_pc. (out_debug_info): Use emit_leb128_expr for DW_AT_high_pc, when DWARF2_VERSION >= 4. * read.c (emit_leb128_exp): No longer static. * read.h (emit_leb128_exp): Define.
2020-08-04gas: Make sure .debug_line file table contains a zero filename and dirMark Wielaard2-9/+34
For DWARF5 the zero file list entry in the .debug_line table represents the compile unit main file. It can be set with .file 0 when -gdwarf-5 is given. But since this directive is illegal for older versions, this is almost never set. To make sure it is always set (so DW_AT_name of the compile unit can be set) use file (and dir) 1 if that is defined (otherwise fall back to pwd, to match DW_AT_comp_dir). gas/ChangeLog: * gas/dwarf2dbg.c (out_dir_and_file_list): For DWARF5 emit at least one directory if there is at least one file. Use dirs[1] if dirs[0] is not set, or if there is no dirs[1] the current working directory. Use files[1] filename, when files[0] filename isn't set.
2020-08-04gas: Fix .debug_info CU header for --gdwarf-5Mark Wielaard7-2/+78
DWARF5 CU headers have a new unit type field and move the abbrev offset to the end of the header. gas/ChangeLog: * dwarf2dbg.c (out_debug_info): Emit unit type and abbrev offset for DWARF5. * gas/testsuite/gas/elf/dwarf-4-cu.d: New file. * gas/testsuite/gas/elf/dwarf-4-cu.s: Likewise. * gas/testsuite/gas/elf/dwarf-5-cu.d: Likewise. * gas/testsuite/gas/elf/dwarf-5-cu.s: Likewise. * testsuite/gas/elf/elf.exp: Run dwarf-4-cu and dwarf-5-cu.
2020-08-04gas: Fix as.texi typo infortmationMark Wielaard2-3/+7
gas/ChangeLog: * doc/as.texi (--gdwarf-[345]): Fix typo.
2020-08-04[gdb/symtab] Handle invalid partial DIE referenceTom de Vries2-3/+7
When reverting commit 9cfd2b89bd "[gdb/testsuite] Fix gdb.arch/amd64-entry-value-paramref.S", we run into an internal-error: ... (gdb) file amd64-entry-value-paramref^M Reading symbols from amd64-entry-value-paramref...^M src/gdb/dwarf2/read.c:18903: internal-error: could not find partial DIE 0x1b7 in cache [from module amd64-entry-value-paramref]^M A problem internal to GDB has been detected,^M further debugging may prove unreliable.^M ... because of invalid dwarf. In contrast, when using -readnow, we have: ... (gdb) file -readnow amd64-entry-value-paramref Reading symbols from amd64-entry-value-paramref... Expanding full symbols from amd64-entry-value-paramref... Dwarf Error: Cannot find DIE at 0x1b7 referenced from DIE at 0x11a \ [in module amd64-entry-value-paramref] (gdb) ... Change the internal error into a Dwarf Error, such that we have: ... (gdb) file amd64-entry-value-paramref^M Reading symbols from amd64-entry-value-paramref...^M Dwarf Error: Cannot not find DIE at 0x1b7 \ [from module amd64-entry-value-paramref]^M ^M (No debugging symbols found in amd64-entry-value-paramref)^M (gdb) ... Build and tested on x86_64-linux. gdb/ChangeLog: 2020-08-04 Tom de Vries <tdevries@suse.de> PR symtab/23270 * dwarf2/read.c (find_partial_die): Change internal error into Dwarf Error.
2020-08-04Automatic date update in version.inGDB Administrator1-1/+1
2020-08-03Update FreeBSD system calls for 13.0-CURRENT.John Baldwin2-2/+19
This matches the current set of system calls in the FreeBSD head development branch as of r363367. Some of these system calls were also included in 12.1 release. gdb/ChangeLog: * syscalls/freebsd.xml: Regenerate.
2020-08-03Fix script name in usage and generated year range.John Baldwin2-2/+6
gdb/ChangeLog: * syscalls/update-freebsd.sh: Fix usage and year range.
2020-08-03MSP430: Remove unused -md GAS optionJozef Lawrynowicz2-9/+7
The MSP430 GAS option "-md" is supposed to indicate that the CRT startup code should copy data from ROM to RAM at startup. However, this option has no effect; GAS handles the related behaviour automatically by looking for the presence of certain symbols in the input file. gas/ChangeLog: * config/tc-msp430.c (OPTION_MOVE_DATA): Remove. (md_parse_option): Remove case for OPTION_MOVE_DATA. (md_longopts): Remove "md" entry. (md_show_usage): Likewise.
2020-08-03[gdb/symtab] Ignore DW_LNE_lo_user/DW_LNE_hi_user rangeTom de Vries6-0/+149
When reading an exec with a .debug_line section containing a vendor-specific extended opcode, we get: ... $ gdb -batch -iex "set complaints 10" dw2-vendor-extended-opcode During symbol reading: mangled .debug_line section ... and reading of the .debug_line section is abandoned. The vendor-specific extended opcode should be ignored, as specified in the DWARF standard (7.1 Vendor Extensibility). [ FWIW, vendor-specific standard opcodes are already ignored. ] Fix this by ignoring all vendor-specific extended opcodes. Build and tested on x86_64-linux. gdb/ChangeLog: 2020-08-03 Tom de Vries <tdevries@suse.de> PR symtab/26333 * dwarf2/read.c (dwarf_decode_lines_1): Ignore DW_LNE_lo_user/DW_LNE_hi_user range. gdb/testsuite/ChangeLog: 2020-08-03 Tom de Vries <tdevries@suse.de> PR symtab/26333 * lib/dwarf.exp (DW_LNE_user): New proc. * gdb.dwarf2/dw2-vendor-extended-opcode.c: New test. * gdb.dwarf2/dw2-vendor-extended-opcode.exp: New file.
2020-08-03asan: alpha-vms: buffer overflow in vms_traverse_indexAlan Modra2-2/+9
* vms-lib.c (vms_traverse_index): Sanity check size remaining before accessing vms_idx or vms_elfidx.
2020-08-03PR26330, Malloc size error in objdumpAlan Modra3-18/+42
PR 26330 * elf.c (_bfd_elf_get_symtab_upper_bound): Sanity check symbol table size against file size. Correct LONG_MAX limit check. (_bfd_elf_get_dynamic_symtab_upper_bound): Likewise. (_bfd_elf_get_reloc_upper_bound): Don't check file size if writing. (_bfd_elf_get_dynamic_reloc_upper_bound): Likewise. * elf64-x86-64-.c (elf_x86_64_get_synthetic_symtab): Use bfd_malloc_and_get_section.
2020-08-03Use xmalloc rather than mallocAlan Modra3-4/+8
As far as I can tell, the following comment is false nowadays. /* Calls to m-alloc get turned by sed into xm-alloc. */ Remove it, and call xmalloc. * ldlex.l (yy_create_string_buffer): Use xmalloc rather than malloc. * lexsup.c (parse_args): Likewise.
2020-08-03PR26328, Compilation warning when building ld v2.35 with MinGWAlan Modra4-13/+34
PR 26328 * configure.ac: AC_CHECK_DECLS asprintf. * configure: Regenerate. * config.in: Regenerate.
2020-08-03Tidy objdump_symstuff and objdump_dynsymstuffAlan Modra3-39/+21
* testsuite/ld-elfvers/vers.exp (objdump_symstuff): Remove unused variable. Init list_a and list_b to empty. (objdump_dynsymstuff): Likewise, and remove undefined list_a handling. * testsuite/ld-elfweak/elfweak.exp (objdump_symstuff): Similarly. (objdump_dynsymstuff): Similarly.
2020-08-03Automatic date update in version.inGDB Administrator1-1/+1
2020-08-02Automatic date update in version.inGDB Administrator1-1/+1
2020-08-01Automatic date update in version.inGDB Administrator1-1/+1
2020-07-31gdb.base/coremaker2.c: Fix compilation problems for x86_64 -m32 multilibKevin Buettner2-7/+14
There are compilation warnings / errors when compiling coremaker2.c for the gdb.base/corefile2.exp tests. Here's the command to use on x86_64 linux: make check RUNTESTFLAGS="--target_board unix/-m32" \ TESTS="gdb.base/corefile2.exp" These are the warnings / errors - I've shortened the paths somewhat: gdb compile failed, gdb/testsuite/gdb.base/coremaker2.c: In function 'main': gdb/testsuite/gdb.base/coremaker2.c:106:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 106 | addr = ((unsigned long long) buf_ro + pagesize) & ~(pagesize - 1); | ^ gdb/testsuite/gdb.base/coremaker2.c:108:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 108 | if (addr <= (unsigned long long) buf_ro | ^ gdb/testsuite/gdb.base/coremaker2.c:109:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 109 | || addr >= (unsigned long long) buf_ro + sizeof (buf_ro)) | ^ gdb/testsuite/gdb.base/coremaker2.c:115:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 115 | mbuf_ro = mmap ((void *) addr, pagesize, PROT_READ, | ^ gdb/testsuite/gdb.base/coremaker2.c:130:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 130 | addr = ((unsigned long long) buf_rw + pagesize) & ~(pagesize - 1); | ^ gdb/testsuite/gdb.base/coremaker2.c:132:15: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 132 | if (addr <= (unsigned long long) buf_rw | ^ gdb/testsuite/gdb.base/coremaker2.c:133:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 133 | || addr >= (unsigned long long) buf_rw + sizeof (buf_rw)) | ^ gdb/testsuite/gdb.base/coremaker2.c:139:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 139 | mbuf_rw = mmap ((void *) addr, pagesize, PROT_READ, | ^ These were fixed by changing unsigned long long to uintptr_t. Tested on either rawhide or Fedora 32 with architectures: x86_64, x86_64/-m32, aarch64, s390x, and ppc64le. gdb/testsuite/ChangeLog: * gdb.base/coremaker2.c: Change all uses of 'unsigned long long' to 'uintptr_t' (inttypes.h): Include.
2020-07-31Fix gdb.base/corefile2.exp test case for ppc64leKevin Buettner2-12/+22
It turns out that the recently added gdb.base/corefile2.exp test won't run on ppc64le linux. The test case fails the internal checks which ensure that a mmap'd region can be placed within the statically allocated regions buf_rw[] and buf_ro[]. ppc64le linux apparently has 64k pages, which is much larger than the 24k regions originally allocated for buf_rw[] and buf_ro[]. This patch increases the size of each region to 256 KiB. Tested on either rawhide or Fedora 32 for these architectures: x86_64, x86_64/-m32, ppc64le, aarch64, and s390x. gdb/testsuite/ChangeLog: * gdb.base/coremaker2.c (buf_rw): Increase size to 256 KiB. (C5_24k): Delete. (C5_8k, C5_64k, C5_256k): New macros. (buf_ro): Allocate 256 KiB of initialized data.
2020-07-31ld: Add -fno-lto to linker testsH.J. Lu7-46/+100
LTO can be used to build binutils with $ CC="gcc -flto -ffat-lto-objects -Wl,--as-needed" CXX="g++ -flto -ffat-lto-objects -Wl,--as-needed" .../configure But not all linker tests are compatible with LTO. Pass -fno-lto to CC to disable LTO on linker tests by default. -flto is passed explicitly to CC in linker LTO tests. * testsuite/ld-elf/indirect.exp: Append -fno-lto to CC. * testsuite/ld-elfvers/vers.exp: Likewise. * testsuite/ld-elfweak/elfweak.exp: Likewise. * testsuite/ld-ifunc/ifunc.exp: Likewise. * testsuite/ld-plugin/lto.exp (no_lto): New. Add $no_lto to build pr15146c.so. * testsuite/lib/ld-lib.exp (at_least_gcc_version): Filter out -Wl,xxx options. (check_gcc_plugin_enabled): Likewise. (run_ld_link_exec_tests): Prepend -fno-lto to $cflags. (run_cc_link_tests): Likewise.
2020-07-31PR26314, Linking LTO objects with symbols from static and shared librariesAlan Modra2-5/+19
gcc -O2 -g -o ar -Wl,--as-needed arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o libbfd-2.35-3.fc33.so libiberty.a -Wl,-R,. All of the above .o files are lto, leading to libbfd-2.35-3.fc33.so not being found needed when loading the IR objects. That's problem number one: We exclude IR references when deciding a shared library is needed. See PR15146. Thus none of the libbfd.so symbols are loaded before libiberty.a is scanned, and libbfd.so contains copies of libiberty.a functions. We ought to be using the libbfd.so copies rather than extracting them from the archive (an object is extracted even to satisfy IR symbols). After lto recompilation, libbfd.so is of course found to be needed and loaded. But that causes more problems. The lto recompilation didn't see symbol references from libbfd.so and variables like _xexit_cleanup are made local in the recompiled objects. Oops, two copies of them. Finally, those silly undefined symbols in the lto output debug files, combined with definitions in both libbfd.so and IR objects result in IR symbols being made dynamic. The main fix here is to revert the PR15146 change to elf_link_add_object_symbols. PR 26314 * elflink.c (bfd_elf_link_record_dynamic_symbol): Don't allow IR symbols to become dynamic. (elf_link_add_object_symbols): Don't exclude IR symbols when deciding whether an as-needed shared library is needed.
2020-07-31ARC: Fix ld/pr24511 testShahab Vahedi2-8/+21
With this patch, ld/pr24511 test passes for ARC. At first glance, the test was failing because the order of "__init_array_start" and "__fini_array_start" weak symbols were reversed: $ nm -n dump.out expected output | real output 00002104 D __init_array_start | 00002104 D __fini_array_start 0000210c D __fini_array_start | 00002104 D __init_array_start The order of the symbols are different as a side effect of both symbols being mapped to the _same_ address (0x2104). Looking further into the mapping logs [1] revealed that the linker script must consider all instances of ".init_array" (in other words ".init_array.*") inside its relevant section. Same logic holds for ".fini_array". Therefore, adding "KEEP (*(SORT(.init_array.*)))" to the linker script, along with the one for ".finit_array.*", resolved the problem. While at it, I took the liberty of refactoring the script a little bit and made those pieces of script macros. [1] Linker's mapping for the relevant part of the test --------------------------------------------------------------- .init_array 0x2104 0x0 0x2104 PROVIDE (__init_array_start = .) *(.init_array) [!provide] PROVIDE (__init_array_end = .) .fini_array 0x2104 0x0 0x2104 PROVIDE (__fini_array_start = .) *(.fini_array) [!provide] PROVIDE (__fini_array_end = .) .data 0x2104 0x0 *(.data .data.* .gnu.linkonce.d.*) .data 0x2104 0x0 pr24511.o .init_array.01000 0x2104 0x8 .init_array.01000 0x2104 0x8 pr24511.o .fini_array.01000 0x210c 0x8 .fini_array.01000 0x210c 0x8 pr24511.o --------------------------------------------------------------- ld: * scripttempl/elfarc.sc (.init_array): Keep ".init_array.*". (.fini_array): Keep ".fini_array.*". Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
2020-07-31Automatic date update in version.inGDB Administrator1-1/+1
2020-07-30x86: Add {disp16} pseudo prefixH.J. Lu16-44/+252
Use Prefix_XXX for pseudo prefixes. Add {disp16} pseudo prefix and replace {disp32} pseudo prefix with {disp16} in 16-bit mode test. Check invalid {disp16}/{disp32} pseudo prefixes. gas/ PR gas/26305 * config/tc-i386.c (_i386_insn::disp_encoding): Add disp_encoding_16bit. (parse_insn): Check Prefix_XXX for pseudo prefixes. Handle {disp16}. (build_modrm_byte): Handle {disp16}. (i386_index_check): Check invalid {disp16} and {disp32} pseudo prefixes. * doc/c-i386.texi: Update {disp32} documentation and document {disp16}. * testsuite/gas/i386/i386.exp: Run x86-64-inval-pseudo. * testsuite/gas/i386/inval-pseudo.s: Add {disp32}/{disp16} tests. * testsuite/gas/i386/pseudos.s: Add {disp8}/{disp32} vmovaps tests with 128-byte displacement. Add {disp16} tests. * testsuite/gas/i386/x86-64-pseudos.s: Add {disp8}/{disp32} vmovaps test. Add (%r13)/(%r13d) tests. * testsuite/gas/i386/x86-64-inval-pseudo.l: New file. * testsuite/gas/i386/x86-64-inval-pseudo.s: Likewise. * testsuite/gas/i386/inval-pseudo.l: Updated. * testsuite/gas/i386/pseudos.d: Likewise. * testsuite/gas/i386/x86-64-pseudos.d: Likewise. opcodes/ PR gas/26305 * i386-opc.h (Prefix_Disp8): New. (Prefix_Disp16): Likewise. (Prefix_Disp32): Likewise. (Prefix_Load): Likewise. (Prefix_Store): Likewise. (Prefix_VEX): Likewise. (Prefix_VEX3): Likewise. (Prefix_EVEX): Likewise. (Prefix_REX): Likewise. (Prefix_NoOptimize): Likewise. * i386-opc.tbl: Use Prefix_XXX on pseudo prefixes. Add {disp16}. * i386-tbl.h: Regenerated.
2020-07-30gdb: handle non-const property types in ada_modulus (PR ada/26318)Simon Marchi2-1/+14
PR 26318 shows that running `maint print symbols` on an Ada binary, compiled with an Ada distribution that includes debug info for the standard library, triggers this assertion: /home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed. The problem is in particular when printing type `system__object_reader__decoded_ada_name__TTdecodedSP1___XDL_0`, which has a dynamic high bound (PROP_LOCLIST kind). When printing a concrete value of this type, this type gets resolved to a type with a constant high bound, so ada_modulus can return this constant value. However, when printing the dynamic range type on its own, such as with `maint print symbols`, the high bound is still of kind PROP_LOCLIST. When ada_modulus tries to access the property as a const value, the assert triggers. There's no sensible numerical value to return in this case. Ideally, ada_modulus would return something to the caller indicating that the value is dynamic and therefore can't be returned as an integer. The callers would handle it, for example `maint print symbols` would say that the high bound of the type is dynamic. However, this patch implements the simpler fix of returning 0 in that case. It kind of restores the previous behavior of before we validated the dynamic property kind in the getters, where we would just return whatever random integer value was in `const_val`. Except now it's consistently 0. This is what we had before we added dynamic property getters: $ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1' typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 107820865988257; and this is what we have now: $ ./gdb -q ~/foo -ex "maint expand-symtabs" -ex "maint print symbols" -batch | grep 'typedef <system__object_reader__decoded_ada_name__TTdecodedSP1' typedef <system__object_reader__decoded_ada_name__TTdecodedSP1: mod 0; The value 107820865988257 is the `baton` field of the property's union interpreted as an integer, so a bogus value. gdb/ChangeLog: PR ada/26318 * ada-lang.c (ada_modulus): Return 0 if property is not of const kind. Change-Id: I3f6d343a9c3cd7cd62a4fc591943a43541223d50
generated by cgit v1.1 at 2024-11-21 15:05:42 +0000