aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-08-07gdb: fix whitespace issues in ChangeLogSimon Marchi2-31/+31
Change-Id: Iea4bd2096bb994ec4ea9145cbe316aa345e8c6db
2020-08-07Fix remaining Ravenscar regressionsTom Tromey2-10/+35
Testing showed a few more Ravenscar regressions arising from upstream. In particular, gdb now uses the current thread in some places where inferior_ptid was previously used. This patch fixes the problem by arranging to save and restore the thread now. gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (ravenscar_thread_target::set_base_thread_from_ravenscar_task): New method. (ravenscar_thread_target::wait): Check runtime_initialized. (ravenscar_thread_target::prepare_to_store) (ravenscar_thread_target::stopped_by_sw_breakpoint) (ravenscar_thread_target::stopped_by_hw_breakpoint) (ravenscar_thread_target::stopped_by_watchpoint) (ravenscar_thread_target::stopped_data_address) (ravenscar_thread_target::core_of_thread): Use scoped_restore_current_thread and set_base_thread_from_ravenscar_task.
2020-08-07Set inferior_ptid in ravenscar_thread_target::update_thread_listTom Tromey2-0/+10
Commit 2da4b788f ("Don't write to inferior_ptid in ravenscar-thread.c") caused a Ravenscar regression (which, FWIW, is understandable because Ravenscar is difficult to test). Namely, ravenscar_thread_target::update_thread_list calls iterate_over_live_ada_tasks, which calls ada_build_task_list, which uses target_has_stack -- which relies on inferior_ptid. This patch changes update_thread_list to ensure that inferior_ptid is set before making this call. This avoids various failures on Ravenscar targets. gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (update_thread_list): Set inferior_ptid.
2020-08-07Fetch registers from correct thread in ravenscar-thread.cTom Tromey2-18/+77
Fabien also noticed that gdb would not report a stop correctly when using Ravenscar. This patch fixes the bug by making a few changes: * ravenscar_thread_target::wait now updates the inferior ptid before updating the thread list. This ensures that a new thread is correctly associated with the underlying CPU. * The fetch_registers, store_registers, and prepare_to_store methods now save and restore the regcache's ptid before doing the operation on the underlying live thread. This ensures that gdb informs the remote of a thread it knows about, as opposed to using a Ravenscar thread, which probably will not be recognized. gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (ravenscar_thread_target::wait): Call update_inferior_ptid before update_thread_list. (temporarily_change_regcache_ptid): New class. (ravenscar_thread_target::fetch_registers) (ravenscar_thread_target::store_registers) (ravenscar_thread_target::prepare_to_store): Use base thread when forwarding operation.
2020-08-07Fix Ravenscar "process" resumeTom Tromey2-1/+11
A coworker noticed that gdb would send the wrong vCont packet to qemu when debugging a Ravenscar program: > (gdb) thread 2 > [Switching to thread 2 (Thread 1.2)] > #0 0x0000000000001000 in ?? () > (gdb) c [...] > Sending packet: $vCont;c:p1.1#e2...Ack Here, we've switched to thread 2, but the packet says to resume thread 1. This turned out to be a bug in ravenscar_thread_target::resume, which did not properly handle the case of a "process" resume. In particular, the resume method would be passed a ptid of (1, 0, 0) -- but then rewrite this to its saved ptid. This patch fixes the problem by recognizing this case in the resume method. gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (ravenscar_thread_target::resume): Handle "is_pid" case.
2020-08-07Update Ravenscar documentationTom Tromey2-0/+33
This documents some recent Ravenscar changes, and further documents the known limitation where stepping through the runtime initialization code does not work properly. gdb/doc/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * gdb.texinfo (Ravenscar Profile): Add examples. Document runtime initialization limitation.
2020-08-07Wrap xfer_partial and enable_btrace for RavenscarTom Tromey2-10/+65
A gdb crash showed that the xfer_partial target method was not wrapped for Ravenscar. This caused remote.c to call remote::set_general_thread with a Ravenscar "fake" ptid, which showed up later as an event ptid. I went through all the target methods and looked to see which ones could call set_general_thread or set_continue_thread (but not set_general_process, as I think Ravenscar targets aren't multi-inferior). This patch wraps the two that I found. xfer_partial requires special treatment, because it can be called recursively via get_base_thread_from_ravenscar_task. To avoid a recursive call, this patch changes update_thread_list to record all tasks in the m_cpu_map, and changes get_thread_base_cpu to prefer this map. This avoids some memory reads. It was unclear to me whether enable_btrace really makes sense for Ravenscar; but at the same time it seemed harmless to add this patch. gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (xfer_partial, enable_btrace, add_thread): New methods. (ravenscar_thread_target::get_thread_base_cpu): Check m_cpu_map first. (ravenscar_thread_target::add_thread): Rename from ravenscar_add_thread. (ravenscar_thread_target::update_thread_list): Use a lambda. (ravenscar_thread_target::xfer_partial): New method.
2020-08-07Use gdb::function_view in iterate_over_live_ada_tasksTom Tromey3-3/+12
This changes iterate_over_live_ada_tasks to accept a gdb::function_view. This is needed by a subsequent patch. gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ada-lang.h (ada_task_list_iterator_ftype): Now a gdb::function_view. (iterate_over_live_ada_tasks): Change type of argument. * ada-tasks.c (iterate_over_live_ada_tasks): Change type of argument.
2020-08-07Change names given to Ravenscar threadsTom Tromey2-9/+12
Current a Ravenscar thread is given the same sort of name as a "CPU" thread; they can only be distinguished by looking at the output of "info thread". This patch changes ravenscar-thread.c to distinguish these threads, like: (gdb) continue Continuing. [New Ravenscar Thread 0x2b910] gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (ravenscar_thread_target) <extra_thread_info>: Remove. (ravenscar_thread_target::extra_thread_info): Remove. (ravenscar_thread_target::pid_to_str): Mention Ravenscar in result; defer to target beneath for non-Ravenscar threads.
2020-08-07Handle case where Ada task is current but not listedTom Tromey2-11/+42
Currently, the ravenscar runtime can mark an Ada task as the current task, before adding it to the list of tasks that can be read by gdb. In this scenario, gdb can sometimes crash in ravenscar_get_thread_base_cpu with: ../../src/gdb/ravenscar-thread.c:167: internal-error: int ravenscar_get_thread_base_cpu(ptid_t): Assertion `task_info != NULL' failed. However, as ravenscar_get_thread_base_cpu is only called to find the base CPU, we can simply record this when registering the thread, and look this up later. gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (ravenscar_thread_target) <get_base_cpu, get_base_thread_from_ravenscar_task>: Now methods. <m_cpu_map>: New member. (ravenscar_thread_target::get_thread_base_cpu): Rename from ravenscar_get_thread_base_cpu. Check m_cpu_map. (ravenscar_thread_target::task_is_currently_active): Update. (ravenscar_thread_target::get_base_thread_from_ravenscar_task): Now a method. (ravenscar_thread_target::add_active_thread): Put initial thread into the m_cpu_map.
2020-08-07Return event_ptid from ravenscar_thread_target::waitTom Tromey2-1/+6
ravenscar_thread_target::wait should return the event ptid from the wrapped "wait" call in the situation where returning the Ravenscar thread ptid is not appropriate. This probably does not really make a difference in practice, but it seemed like a reasonable cleanup. gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (ravenscar_thread_target::wait): Return event_ptid.
2020-08-07Avoid crash in ravenscar_thread_target::waitTom Tromey2-1/+7
An earlier patch caused a Ravenscar regression in ravenscar_thread_target::wait. In particular, add_active_thread can return NULL when the runtime is not initialized. gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (ravenscar_thread_target::wait): Check runtime_initialized.
2020-08-07Call add_active_thread after pushing the ravenscar targetTom Tromey2-6/+15
Currently ravenscar-thread.c calls add_active_thread before pushing the ravenscar target. This yields an initial thread announcement of "[Thread 0]". Calling add_active_thread after pushing the target fixes this. gdb/ChangeLog 2020-08-07 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (ravenscar_thread_target): Don't call add_active_thread. (ravenscar_thread_target::add_active_thread): Now public. (ravenscar_inferior_created): Call add_active_thread after pushing the target.
2020-08-07gdb: change regcache list to be a mapSimon Marchi4-42/+125
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). Same goes for resuming a thread (need to delete the regcache of a given ptid) and resuming all threads. It becomes noticeable when debugging thousands of threads, which is typical with GPU targets. This patch replaces the linked list with some maps to reduce that complexity. The first design was 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. If the key of the map is (target, ptid, arch), we have to walk all items of the map, not good. The second design was therefore using an std::unordered_multimap with (target, ptid) as the key. One key could be associated to multiple regcaches, all with different gdbarches. When looking up, we would have to walk all these regcaches. This would be ok, because there will usually be actually one matching regcache. In the exceptional multi-arch thread cases, there will be maybe two. However, in registers_changed_ptid, we sometimes need to remove all regcaches matching a given target. We would then have to talk all items of the map again, not good. The design as implemented in this patch therefore uses two levels of map. One std::unordered_map uses the target as the key. The value type is an std::unordered_multimap that itself uses the ptid as the key. The values of the multimap are the regcaches themselves. Again, we expect to have one or very few regcaches per (target, ptid). So, in summary: * The lookups (in get_thread_arch_aspace_regcache), 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 map lookups 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). It 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 - a non-NULL target and minus_one_ptid: we delete all the entries associated to that target * 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. 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 (ptid_regcache_map): New type. (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. * regcache.h (regcache_up): New type. * gdbsupport/ptid.h (hash_ptid): New struct. Change-Id: Iabb0a1111707936ca111ddb13f3b09efa83d3402
2020-08-07gdb: pass target to thread_ptid_changed observableSimon Marchi5-7/+167
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-07Add code for processing version 5 DWP files (for use with DWARF v5).Caroline Tice2-52/+460
The DWARF v5 Spec describes a (slightly) new format for V5 .dwp files. This patch updates GDB to allow it to read/process .dwp files in the new DWARF v5 format, while continuing to be able to read/process .dwp files in the older V1 & V2 formats (older, pre-standard formats). The two major differences between the V2 and the V5 format are: - The inclusion of DWARF-v5-specific sections: .debug_loclists.dwo .debug_rnglists.dwo - The .dwp section identifier encodings have changed. The table below shows the old & new encodings. Notice the re-purposing of 5, 7 & 8 in particular. Val DW4 section DW4 section id DW5 section DW5 section id --- ----------------- -------------- ----------------- -------------- 1 .debug_info.dwo DW_SECT_INFO .debug_info.dwo DW_SECT_INFO 2 .debug_types.dwo DW_SECT_TYPES -- reserved 3 .debug_abbrev.dwo DW_SECT_ABBREV .debug_abbrev.dwo DW_SECT_ABBREV 4 .debug_line.dwo DW_SECT_LINE .debug_line.dwo DW_SECT_LINE 5 .debug_loc.dwo DW_SECT_LOC .debug_loclists.dwo DW_SECT_LOCLISTS 6 .debug_str_offsets.dwo .debug_str_offsets.dwo DW_SECT_STR_OFFSETS DW_SECT_STR_OFFSETS 7 .debug_macinfo.dwo DW_SECT_MACINFO .debug_macro.dwo DW_SECT_MACRO 8 .debug_macro.dwo DW_SECT_MACRO .debug_rnglists.dwo DW_SECT_RNGLISTS
2020-08-07as: Ignore rest of line on overflow errorH.J. Lu2-1/+9
* read.c (read_a_source_file): Ignore rest of line on overflow error.
2020-08-07MSP430: sim: Increase main memory region sizeJozef Lawrynowicz2-1/+6
The area between 0xFF00 and 0xFFC0 is unallocated in the simulator memory map, so extend the main memory region up to 0xFFC0 to allow the simulator to make use of the extra 192 bytes of space. sim/msp430/ChangeLog: * msp430-sim.c (sim_open): Increase the size of the main memory region to 0xFAC0.
2020-08-07Automatic date update in version.inGDB Administrator1-1/+1
2020-08-06gdb: move regcache::regcaches to regcache.cSimon Marchi6-50/+52
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-06gdb: rename regcache::current_regcache to regcache::regcachesSimon Marchi3-32/+45
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-06gas: Fix internal error on long local labelsAlex Coplan6-3/+32
Prior to this commit, on an input such as "88888888888:", GAS hits a signed integer overflow and likely an assertion failure. I see: $ echo "88888888888:" | bin/aarch64-none-elf-as {standard input}: Assembler messages: {standard input}:1: Internal error in fb_label_name at ../gas/symbols.c:2049. Please report this bug. To fix this issue, I've taken two steps: 1. Change the type used for processing local labels in read_a_source_file() from int to long, to allow representing more local labels, and also since all uses of this variable (temp) are actually of type long. 2. Detect if we would overflow and bail out with an error message instead of actually overflowing and hitting the assertion in fb_label_name(). gas/ChangeLog: 2020-08-06 Alex Coplan <alex.coplan@arm.com> * read.c (read_a_source_file): Use long for local labels, detect overflow and raise an error for overly-long labels. * testsuite/gas/all/gas.exp: Add local-label-overflow test. * testsuite/gas/all/local-label-overflow.d: New test. * testsuite/gas/all/local-label-overflow.l: Error output. * testsuite/gas/all/local-label-overflow.s: Input.
2020-08-06amd64_analyze_prologue: fix incorrect commentVictor Collod2-1/+5
The width of the instruction didn't match the size of its operands. 2020-06-23 Victor Collod <vcollod@nvidia.com> * amd64-tdep.c (amd64_analyze_prologue): Fix incorrect comment. Change-Id: I104ebfe0b3c24bd6a8d0f0c5a791b9676a930a54
2020-08-06bpf: relocation fixes for eBPF ELF backendDavid Faust17-48/+371
The eBPF ELF backend was not properly recording relocation addends during installation, nor reading and applying them when performing the final relocation. This lead to various issues with incorrect relocations. These issues are fixed with a new howto special function to install the relocations, and updates to bpf_elf_relocate_section to read and use the addends as recorded in the input_bfd. bfd/ChangeLog 2020-08-05 David Faust <david.faust@oracle.com> * elf64-bpf.c (bpf_elf_generic_reloc): New function. (bpf_elf_howto_table): Use it here. (bpf_elf_relocate_section): Use addends recorded in input_bfd for instruction and data relocations. ld/ChangeLog 2020-08-05 David Faust <david.faust@oracle.com> * testsuite/ld-bpf/call-2.s: New file. * testsuite/ld-bpf/call-2.d: Likewise. * testsuite/ld-bpf/reloc-data-be.d: Likewise. * testsuite/ld-bpf/reloc-data-le.d: Likewise. * testsuite/ld-bpf/reloc-data.s: Likewise. * testsuite/ld-bpf/reloc-insn-external-be.d: Likewise. * testsuite/ld-bpf/reloc-insn-external-le.d: Likewise. * testsuite/ld-bpf/reloc-insn-external.s: Likewise. * testsuite/ld-bpf/reloc-insn32-be.d: Likewise. * testsuite/ld-bpf/reloc-insn32-le.d: Likewise. * testsuite/ld-bpf/reloc-insn32.s: Likewise. * testsuite/ld-bpf/reloc-insn64-be.d: Likewise. * testsuite/ld-bpf/reloc-insn64-le.d: Likewise. * testsuite/ld-bpf/reloc-insn64.s: Likewise.
2020-08-06MSP430: ld: Update output section tail when shuffling ".either" sectionsJozef Lawrynowicz2-10/+31
The MSP430 linker shuffles input sections with names beginning with ".either" between the upper and lower memory regions, to try to avoid one region overflowing when there is space in the other region. However, when an ".either" input section attached to the tail of an output section was moved to a different output section in the other region, that tail wasn't being updated to the new section at the end of the original output section. This caused a bug where a shuffled section could end up in the middle of another section in the output executable, resulting in corrupted code or data. When changing the output section of an input section attached to the tail of its output section, that tail is now updated to point to the new input section at the end of the section list. ld/ChangeLog: 2020-08-06 Jozef Lawrynowicz <jozef.l@mittosystems.com> * emultempl/msp430.em (change_output_section): Update the tail of the output section statement list when moving the original tail to a different output section. (eval_upper_either_sections): Don't move sections from the upper region to the lower region unless the upper region is overflowing.
2020-08-05Don't output null pathname in core_target::build_file_mappings warningKevin Buettner2-1/+6
While looking into the regressions reported by Luis Machado, I noticed that null pathnames were being output in the warnings. E.g. warning: Can't open file (null) during file-backed mapping note processing I've changed the warning to output the pathname found in the note, like this: warning: Can't open file /var/lib/docker/aufs/diff/d07c...e21/lib/x86_64-linux-gnu/libc-2.27.so during file-backed mapping note processing (I've shortened one of the path elements above.) gdb/ChangeLog: * corelow.c (core_target::build_file_mappings): Don't output null pathname in warning.
2020-08-06Automatic date update in version.inGDB Administrator1-1/+1
2020-08-05gdb/testsuite: link some dwarf2 tests with nopieSimon Marchi7-6/+14
I noticed some gdb.dwarf2 tests not running on my machine because of this: Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/dw2-single-line-discriminators.exp ... gdb compile failed, /usr/bin/ld: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw2-single-line-discriminators/dw2-single-line-discriminators0.o: relocation R_X86_64_32S against symbol `x' can not be used when making a PIE object; recompile with -fPIE collect2: error: ld returned 1 exit status We get this when the target toolchain produces position-independent executables by default. These tests are built from some assembly which produces some relocations incompatible with position-independent executables. Add `nopie` to the compilation flags of these tests to force the toolchain to produce non-position-independent executables. With this, the changed tests run successfully on my machine. gdb/ChangeLog: * gdb.dwarf2/clztest.exp, gdb.dwarf2/dw2-common-block.exp, gdb.dwarf2/dw2-dup-frame.exp, gdb.dwarf2/dw2-reg-undefined.exp, gdb.dwarf2/dw2-single-line-discriminators.exp, dw2-undefined-ret-addr.exp: Pass nopie to compilation options. Change-Id: Ie06c946f8e56a6030be247d1c57f416fa8b67e4c
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.
generated by cgit v1.1 at 2025-01-12 11:07:28 +0000