aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-04-29Add a vtable-based breakpoint opsTom Tromey2-0/+223
This adds methods to struct breakpoint. Each method has a similar signature to a corresponding function in breakpoint_ops, with the exceptions of create_sals_from_location and create_breakpoints_sal, which can't be virtual methods on breakpoint -- they are only used during the construction of breakpoints. Then, this adds a new vtable_breakpoint_ops structure and populates it with functions that simply forward a call from breakpoint_ops to the corresponding virtual method. These are all done with lambdas, because they are just a stepping stone -- by the end of the series, this structure will be deleted.
2022-04-29Return bool from breakpoint_ops::print_oneTom Tromey9-19/+45
This changes breakpoint_ops::print_one to return bool, and updates all the implementations and the caller. The caller is changed so that a NULL check is no longer needed -- something that will be impossible with a real method.
2022-04-29Delete some unnecessary wrapper functionsTom Tromey1-64/+4
This patch deletes a few unnecessary wrapper functions from breakpoint.c.
2022-04-29Add an assertion to clone_momentary_breakpointTom Tromey1-0/+1
This adds an assertion to clone_momentary_breakpoint. This will eventually be removed, but in the meantime is is useful for helping convince oneself that momentary breakpoints will always use momentary_breakpoint_ops. This understanding will help when cleaning up the code later.
2022-04-29Boolify print_solib_eventTom Tromey3-5/+5
Change print_solib_event to accept a bool parameter and update the callers.
2022-04-29Move "catch load" to a new fileTom Tromey4-258/+311
The "catch load" code is reasonably self-contained, and so this patch moves it out of breakpoint.c and into a new file, break-catch-load.c. One function from breakpoint.c, print_solib_event, now has to be exposed, but this seems pretty reasonable.
2022-04-29gprofng: assertion in gprofng/src/Expression.cc:139Vladimir Mezentsev2-18/+18
gprofng/ChangeLog 2022-04-28 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR gprofng/29102 * src/Expression.h: Remove fixupValues. * src/Expression.cc (Expression::copy): Fix a bug.
2022-04-29De-duplicate .gdb_indexTom Tromey1-2/+23
This de-duplicates variables and types in .gdb_index, making the new index closer to what gdb generated before the new DWARF scanner series. Spot-checking the resulting index for gdb itself, it seems that the new scanner picks up some extra symbols not detected by the old one. I tested both the new and old versions of gdb on both new and old versions of the index, and startup time in all cases is roughly the same (it's worth noting that, for gdb itself, the index no longer provides any benefit over the DWARF scanner). So, I think this fixes the size issue with the new index writer. Regression tested on x86-64 Fedora 34.
2022-04-29Fix .debug_names regression with new indexerTom Tromey3-3/+85
At AdaCore, we run the internal gdb test suite in several modes, including one using the .debug_names index. This caught a regression caused by the new DWARF indexer. First, the psymtabs-based .debug_names generator was completely wrong. However, to avoid making the rewrite series even bigger (fixing the writer will also require rewriting the .debug_names reader), it attempted to preserve the weirdness. However, this was not done properly. For example the old writer did this: - case STRUCT_DOMAIN: - return DW_TAG_structure_type; The new code, instead, simply preserves the actual DWARF tag -- but this makes future lookups fail, because the .debug_names reader only looks for DW_TAG_structure_type. This patch attempts to revert to the old behavior in the writer.
2022-04-29gdb/infrun: make fetch_inferior_event restore thread if exited or signalledSimon Marchi1-3/+7
Commit 152a1749566 ("gdb: prune inferiors at end of fetch_inferior_event, fix intermittent failure of gdb.threads/fork-plus-threads.exp") introduced some follow-fork-related test failures, such as: info inferiors^M Num Description Connection Executable ^M * 1 process 634972 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M 2 process 634975 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info inferiors inferior 2^M [Switching to inferior 2 [process 634975] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]^M [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 634975))]^M #0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6^M (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: inferior 2 continue^M Continuing.^M [Inferior 2 (process 634975) exited normally]^M [Switching to Thread 0x7ffff7c9a740 (LWP 634972)]^M (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: continue until exit at continue unfollowed inferior to end break callee^M Breakpoint 2 at 0x555555555160: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c, line 9.^M (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: break callee What happens here is: - inferior 2 is selected - we continue, leading to inferior 2's exit - we set breakpoint, expect 2 locations, but only one location is resolved Reading between the lines, we understand that inferior 2 got pruned, when it shouldn't have been. The issue can be reproduced by hand with: $ ./gdb -q --data-directory=data-directory testsuite/outputs/gdb.base/foll-fork/foll-fork -ex "set detach-on-fork off" -ex start -ex "next 2" -ex "inferior 2" -ex "set debug infrun" ... Temporary breakpoint 1, main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:14 14 int v = 5; [New inferior 2 (process 637627)] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". 17 if (pid == 0) /* set breakpoint here */ [Switching to inferior 2 [process 637627] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)] [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 637627))] #0 0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6 (gdb) continue Continuing. [infrun] clear_proceed_status_thread: 637627.637627.0 [infrun] proceed: enter [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT [infrun] scoped_disable_commit_resumed: reason=proceeding [infrun] start_step_over: enter [infrun] start_step_over: stealing global queue of threads to step, length = 0 [infrun] operator(): step-over queue now empty [infrun] start_step_over: exit [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop [infrun] proceed: resuming 637627.637627.0 [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [637627.637627.0] at 0x7ffff7d7abf7 [infrun] do_target_resume: resume_ptid=637627.637627.0, step=0, sig=GDB_SIGNAL_0 [infrun] infrun_async: enable=1 [infrun] prepare_to_wait: prepare_to_wait [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop [infrun] reset: reason=proceeding [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target native [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native [infrun] proceed: exit [infrun] fetch_inferior_event: enter [infrun] scoped_disable_commit_resumed: reason=handling event [infrun] do_target_wait: Found 2 inferiors, starting at #1 [infrun] random_pending_event_thread: None found. [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = [infrun] print_target_wait_results: 637627.637627.0 [process 637627], [infrun] print_target_wait_results: status->kind = EXITED, exit_status = 0 [infrun] handle_inferior_event: status->kind = EXITED, exit_status = 0 [Inferior 2 (process 637627) exited normally] [infrun] stop_waiting: stop_waiting [infrun] stop_all_threads: start: reason=presenting stop to user in all-stop, inf=-1 [infrun] stop_all_threads: pass=0, iterations=0 [infrun] stop_all_threads: 637624.637624.0 not executing [infrun] stop_all_threads: pass=1, iterations=1 [infrun] stop_all_threads: 637624.637624.0 not executing [infrun] stop_all_threads: done [infrun] stop_all_threads: end: reason=presenting stop to user in all-stop, inf=-1 [Switching to Thread 0x7ffff7c9a740 (LWP 637624)] [infrun] infrun_async: enable=0 [infrun] reset: reason=handling event [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads (gdb) [infrun] fetch_inferior_event: exit (gdb) info inferiors Num Description Connection Executable * 1 process 637624 1 (native) /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork (gdb) i th Id Target Id Frame * 1 Thread 0x7ffff7c9a740 (LWP 637624) "foll-fork" main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:17 After handling the EXITED event for inferior 2, inferior 2 should have stayed the current inferior, which should have prevented it from getting pruned. When debugging, we find that when getting at the prune_inferiors call, the current inferior is inferior 1. Further debugging shows that prior to the call to clean_up_just_stopped_threads_fsms, the current inferior is inferior 2, and after, it's inferior 1. Then, back in fetch_inferior_event, the restore_thread object is disabled, due to: /* If we got a TARGET_WAITKIND_NO_RESUMED event, then the previously selected thread is gone. We have two choices - switch to no thread selected, or restore the previously selected thread (now exited). We chose the later, just because that's what GDB used to do. After this, "info threads" says "The current thread <Thread ID 2> has terminated." instead of "No thread selected.". */ if (!non_stop && cmd_done && ecs->ws.kind () != TARGET_WAITKIND_NO_RESUMED) restore_thread.dont_restore (); So in the end, inferior 1 stays current, and inferior 2 gets wrongfully pruned. I'd say clean_up_just_stopped_threads_fsms is the culprit here. It actually attempts to restore the event_thread to be current at the end, after the loop (I presume the current thread on entry is always supposed to be the event thread). But in this case, the event is of kind EXITED, and ecs->event_thread is not set, so the current inferior isn't restored. Fix that by using scoped_restore_current_thread. If there is no current thread, scoped_restore_current_thread will still restore the current inferior, and that's what we want. Random note: the thread_info object for inferior 2's thread is never freed. It is held (by refcount) by the restore_thread object in fetch_inferior_event, while the inferior's thread list gets cleared, in the exit event processing. When the refcount reaches 0 (when the restore_thread object is destroyed), there's nothing that actually deletes the thread_info object. And I think that nothing in GDB points to it anymore, so it leaks. I don't want to fix that in this patch, but thought it would be good to mention it, in case somebody has an idea for how to fix that. Change-Id: Ibc7df543e2c46aad5f3b9250b28c3fb5912be4e8
2022-04-29Slightly tweak and clarify target_resume's interfacePedro Alves4-62/+63
The current target_resume interface is a bit odd & non-intuitive. I've found myself explaining it a couple times the recent past, while reviewing patches that assumed STEP/SIGNAL always applied to the passed in PTID. It goes like this today: - if the passed in PTID is a thread, then the step/signal request is for that thread. - otherwise, if PTID is a wildcard (all threads or all threads of process), the step/signal request is for inferior_ptid, and PTID indicates which set of threads run free. Because GDB always switches the current thread to "leader" thread being resumed/stepped/signalled, we can simplify this a bit to: - step/signal are always for inferior_ptid. - PTID indicates the set of threads that run free. Still not ideal, but it's a minimal change and at least there are no special cases this way. That's what this patch does. It renames the PTID parameter to SCOPE_PTID, adds some assertions to target_resume, and tweaks target_resume's description. In addition, it also renames PTID to SCOPE_PTID in the remote and linux-nat targets, and simplifies their implementation a little bit. Other targets could do the same, but they don't have to. Change-Id: I02a2ec2ab3a3e9b191de1e9a84f55c17cab7daaf
2022-04-29Automatic date update in version.inGDB Administrator1-1/+1
2022-04-28Fix libinproctrace.so build on PPCTom Tromey1-1/+2
The recent gnulib import caused a build failure of libinproctrace.so on PPC: alloc.c:(.text+0x20): undefined reference to `rpl_malloc' alloc.c:(.text+0x70): undefined reference to `rpl_realloc' This patch fixes the problem using the same workaround that was previously used for free.
2022-04-28x86: Properly handle function pointer referenceH.J. Lu4-38/+102
Update commit ebb191adac4ab45498dec0bfaac62f0a33537ba4 Author: H.J. Lu <hjl.tools@gmail.com> Date: Wed Feb 9 15:51:22 2022 -0800 x86: Disallow invalid relocation against protected symbol to allow function pointer reference and make sure that PLT entry isn't used for function reference due to function pointer reference. bfd/ PR ld/29087 * elf32-i386.c (elf_i386_scan_relocs): Don't set pointer_equality_needed nor check non-canonical reference for function pointer reference. * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. ld/ PR ld/29087 * testsuite/ld-x86-64/x86-64.exp: Run PR ld/29087 tests. * testsuite/ld-x86-64/protected-func-3.c: New file.
2022-04-28Check OBJF_NOT_FILENAME in DWARF index codeTom Tromey2-6/+7
The DWARF index code currently uses 'stat' to see if an objfile represents a real file. However, I think it's more correct to check OBJF_NOT_FILENAME instead. Regression tested on x86-64 Fedora 34.
2022-04-28Remove "typedef enum ..."Tom Tromey14-38/+35
I noticed a few spots in GDB that use "typedef enum". However, in C++ this isn't as useful, as the tag is automatically entered as a typedef. This patch removes most uses of "typedef enum" -- the exceptions being in some nat-* code I can't compile, and glibc_thread_db.h, which I think is more or less a copy of some C code from elsewhere. Tested by rebuilding.
2022-04-28gdb: fix nullptr dereference in block::ranges()Andrew Burgess1-2/+12
This commit: commit f5cb8afdd297dd68273d98a10fbfd350dff918d8 Date: Sun Feb 6 22:27:53 2022 -0500 gdb: remove BLOCK_RANGES macro introduces a potential nullptr dereference in block::ranges, this is breaking most tests, e.g. gdb.base/break.exp is failing for me. In the above patch BLOCK_CONTIGUOUS_P is changed from this: #define BLOCK_CONTIGUOUS_P(bl) (BLOCK_RANGES (bl) == nullptr \ || BLOCK_NRANGES (bl) <= 1) to this: #define BLOCK_CONTIGUOUS_P(bl) ((bl)->ranges ().size () == 0 \ || (bl)->ranges ().size () == 1) So, before the commit we checked for the block ranges being nullptr, but afterwards we just call block::ranges() in all cases. The problem is that block::ranges() looks like this: /* Return a view on this block's ranges. */ gdb::array_view<blockrange> ranges () { return gdb::make_array_view (m_ranges->range, m_ranges->nranges); } where m_ranges is: struct blockranges *m_ranges; And so, we see that the nullptr check has been lost, and we might end up dereferencing a nullptr. My proposed fix is to move the nullptr check into block::ranges, and return an explicit empty array_view if m_ranges is nullptr. After this, everything seems fine again.
2022-04-28s390: Add DT_JMPREL pointing to .rela.[i]plt with static-pieStefan Liebler1-1/+14
In static-pie case, there are IRELATIVE-relocs in .rela.iplt (htab->irelplt), which will later be grouped to .rela.plt. On s390, the IRELATIVE relocations are always located in .rela.iplt - even for non-static case. Ensure that DT_JMPREL, DT_PLTRELA, DT_PLTRELASZ is added to the dynamic section even if htab->srelplt->size == 0. See _bfd_elf_add_dynamic_tags in bfd/elflink.c. bfd/ elf64-s390.c (elf_s390_size_dynamic_sections): Enforce DT_JMPREL via htab->elf.dt_jmprel_required.
2022-04-28s390: Avoid dynamic TLS relocs in PIEStefan Liebler1-13/+13
No dynamic relocs are needed for TLS defined in an executable, the TP relative offset is known at link time. Fixes FAIL: Build pr22263-1 bfd/ PR ld/22263 * elf64-s390.c (elf_s390_tls_transition): Use bfd_link_dll instead of bfd_link_pic for TLS. (elf_s390_check_relocs): Likewise. (allocate_dynrelocs): Likewise. (elf_s390_relocate_section): Likewise.
2022-04-28libctf: impose an ordering on conflicting typesNick Alcock7-2/+98
When two types conflict and they are not types which can have forwards (say, two arrays of different sizes with the same name in two different TUs) the CTF deduplicator uses a popularity contest to decide what to do: the type cited by the most other types ends up put into the shared dict, while the others are relegated to per-CU child dicts. This works well as long as one type *is* most popular -- but what if there is a tie? If several types have the same popularity count, we end up picking the first we run across and promoting it, and unfortunately since we are working over a dynhash in essentially arbitrary order, this means we promote a random one. So multiple runs of ld with the same inputs can produce different outputs! All the outputs are valid, but this is still undesirable. Adjust things to use the same strategy used to sort types on the output: when there is a tie, always put the type that appears in a CU that appeared earlier on the link line (and if there is somehow still a tie, which should be impossible, pick the type with the lowest type ID). Add a testcase -- and since this emerged when trying out extern arrays, check that those work as well (this requires a newer GCC, but since all GCCs that can emit CTF at all are unreleased this is probably OK as well). Fix up one testcase that has slight type ordering changes as a result of this change. libctf/ChangeLog: * ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use cd_output_first_gid to break ties. ld/ChangeLog: * testsuite/ld-ctf/array-conflicted-ordering.d: New test, using... * testsuite/ld-ctf/array-char-conflicting-1.c: ... this... * testsuite/ld-ctf/array-char-conflicting-2.c: ... and this. * testsuite/ld-ctf/array-extern.d: New test, using... * testsuite/ld-ctf/array-extern.c: ... this. * testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering changes.
2022-04-28libctf: add a comment explaining how to use ctf_*openNick Alcock1-1/+7
Specifically, tell users what to pass to those functions that accept raw section content, since it's fairly involved and easy to get wrong. (.dynsym / .dynstr when CTF_F_DYNSTR is set, otherwise .symtab / .strtab). include/ChangeLog: * ctf-api.h (ctf_*open): Improve comment.
2022-04-27gprofng: test suite problemsVladimir Mezentsev1-2/+2
gprofng/ChangeLog 2022-04-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR gprofng/29065 * testsuite/lib/Makefile.skel: Search parent dir for libs too.
2022-04-27gdb: remove BLOCKVECTOR_MAP macroSimon Marchi7-17/+26
Replace with equivalent methods. Change-Id: I4e56c76dfc363c1447686fb29c4212ea18b4dba0
2022-04-27gdb: constify addrmap_findSimon Marchi2-9/+9
addrmap_find shouldn't need to modify the addrmap, so constify the addrmap parameter. This helps for the following patch, where getting the map of a const blockvector will return a const addrmap. Change-Id: If670e425ed013724a3a77aab7961db50366dccb2
2022-04-27gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macrosSimon Marchi25-161/+194
Replace with calls to blockvector::blocks, and the appropriate method call on the returned array_view. Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
2022-04-27gdb: remove BLOCK_ENTRY_PC macroSimon Marchi17-51/+56
Replace with equivalent method. Change-Id: I0e033095e7358799930775e61028b48246971a7d
2022-04-27gdb: remove BLOCK_CONTIGUOUS_P macroSimon Marchi3-9/+8
Replace with an equivalent method. Change-Id: I60fd3be7b4c2601c2a74328f635fa48ed80eb7f5
2022-04-27gdb: remove BLOCK_RANGE macroSimon Marchi1-5/+1
Replace with access through the block::ranges method. Change-Id: I50f3ed433b997c9f354e49bc6583f540ae4b6121
2022-04-27gdb: remove BLOCK_NRANGES macroSimon Marchi3-19/+15
Replace with range for loops. Change-Id: Icbe04f9b6f9e6ddae2e15b2409c61f7a336bc3e3
2022-04-27gdb: remove BLOCK_RANGES macroSimon Marchi3-17/+24
Replace with an equivalent method on struct block. Change-Id: I6dcf13e9464ba8a08ade85c89e7329c300fd6c2a
2022-04-27gdb: remove BLOCK_RANGE_{START,END} macrosSimon Marchi4-26/+35
Replace with equivalent methods on blockrange. Change-Id: I20fd8f624e0129782c36768291891e7582d77c74
2022-04-27gdb: remove BLOCK_NAMESPACE macroSimon Marchi2-13/+19
Replace with equivalent methods. Change-Id: If86b8cbdfb0f52e22c929614cd53e73358bab76a
2022-04-27gdb: remove BLOCK_MULTIDICT macroSimon Marchi7-30/+37
Replace with equivalent methods. Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2
2022-04-27gdb: remove BLOCK_SUPERBLOCK macroSimon Marchi26-84/+92
Replace with equivalent methods. Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
2022-04-27gdb: remove BLOCK_FUNCTION macroSimon Marchi24-69/+74
Replace with equivalent methods. Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-27gdb: remove BLOCK_{START,END} macrosSimon Marchi20-99/+117
Replace with equivalent methods. Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
2022-04-28Automatic date update in version.inGDB Administrator1-1/+1
2022-04-27x86: Disable 2 tests with large memory requirementH.J. Lu2-3/+4
gas/ * testsuite/gas/i386/i386.exp: Disable rept. ld/ * testsuite/ld-x86-64/x86-64.exp: Disable pr17618.
2022-04-27Make gdb.base/parse_number.exp test all architecturesPedro Alves1-11/+63
There are some subtle differences between architectures, like the size of a "long" type, and this isn't currently accounted for in gdb.base/parse_number.exp. For example, on aarch64 a long type is 8 bytes, whereas a long type is 4 bytes for x86_64. This causes the following FAIL's: FAIL: gdb.base/parse_number.exp: lang=asm: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=auto: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=c: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=c++: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=fortran: p/x 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=fortran: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=go: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=local: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=minimal: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=objective-c: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=opencl: ptype 0xffffffffffffffff FAIL: gdb.base/parse_number.exp: lang=pascal: ptype 0xffffffffffffffff There are some fortran-specific divergences as well, where 32-bit architectures show "unsigned int" for both 32-bit and 64-bit integers and 64-bit architectures show "unsigned int" and "unsigned long" for 32-bit and 64-bit integers. There might be a bug that 32-bit fortran truncates 64-bit values to 32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff". Here's what we get for aarch64: (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff type = unsigned long (gdb) p sizeof (0xffffffff) $1 = 4 (gdb) p sizeof (0xffffffffffffffff) quit $2 = 8 (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff type = unsigned long And for arm: (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff quit type = unsigned long long (gdb) p sizeof (0xffffffff) quit $1 = 4 (gdb) p sizeof (0xffffffffffffffff) quit $2 = 8 (gdb) ptype 0xffffffff type = unsigned int (gdb) ptype 0xffffffffffffffff type = unsigned long This patch... * Makes the testcase iterate over all architectures, thus covering all the different combinations of types/sizes every time. * Adjusts the expected values and types based on the sizes of long long, long and int. A particularly curious architecture is s12z, which has 32-bit long long, and thus no way to represent 64-bit integers in C-like languages. Co-Authored-By: Luis Machado <luis.machado@arm.com> Change-Id: Ifc0ccd33e7fd3c7585112ff6bebe7d266136768b
2022-04-27Fix gdbserver build for x86-64 WindowsTom Tromey3-28/+36
I broke the gdbserver build on x86-64 Windows a little while back. Previously, I could not build this configuration, but today I found out that if I configure with: --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 using the Fedora 34 tools, it will in fact build. I'm not certain, but maybe the gnulib update helped with this. This patch fixes the build. I'm checking it in.
2022-04-27Create pseudo sections for NT_ARM_TLS notes on FreeBSD.John Baldwin2-0/+7
bfd/ChangeLog: * elf.c (elfcore_grok_freebsd_note): Handle NT_ARM_TLS notes.
2022-04-27gdb/arm: Extend arm_m_addr_is_magic to support FNC_RETURN, add ↵Christophe Lyon3-62/+267
unwind-secure-frames command This patch makes use of the support for several stack pointers introduced by the previous patch to switch between them as needed during unwinding. It introduces a new 'unwind-secure-frames' arm command to enable/disable mode switching during unwinding. It is enabled by default. It has been tested using an STM32L5 board (with cortex-m33) and the sample applications shipped with the STM32Cube development environment: GTZC_TZSC_MPCBB_TrustZone in STM32CubeL5/Projects/NUCLEO-L552ZE-Q/Examples/GTZC. The test consisted in setting breakpoints in various places and check that the backtrace is correct: SecureFault_Callback (Non-secure mode), __gnu_cmse_nonsecure_call (before and after the vpush instruction), SecureFault_Handler (Secure mode). This implies that we tested only some parts of this patch (only MSP* were used), but remaining parts seem reasonable. Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Add support for multiple stack pointers on Cortex-MChristophe Lyon4-20/+284
Armv8-M architecture with Security extension features four stack pointers to handle Secure and Non-secure modes. This patch adds support to switch between them as needed during unwinding, and replaces all updates of cache->prev_sp with calls to arm_cache_set_prev_sp. Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Introduce arm_cache_initChristophe Lyon1-6/+27
This patch is a preparation for the rest of the series and adds two arm_cache_init helper functions. It updates every place that updates cache->saved_regs to call the helper instead. Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Define MSP and PSP registers for M-ProfileChristophe Lyon7-29/+89
This patch removes the hardcoded access to PSP in arm_m_exception_cache() and relies on the definition with the XML descriptions. Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Fix prologue analysis to support vpushChristophe Lyon1-0/+29
While working on adding support for Non-secure/Secure modes unwinding, I noticed that the prologue analysis lacked support for vpush, which is used for instance in the CMSE stub routine. This patch updates thumb_analyze_prologue accordingly, adding support for vpush of D-registers. Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/testsuite: fix FAIL in gdb.base/clear_non_user_bp.expEnze Li1-18/+48
Tom and Simon feedback that there is a test failing in this commit: commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6 Date: Sun Apr 17 15:09:46 2022 +0800 gdb: fix using clear command to delete non-user breakpoints(PR cli/7161) Then, I reproduced the same fail with Ubuntu 20.04 as Simon said, and I fixed the nit in this patch. The root of the problem is not correctly matching the presentation of internal breakpoints. In addition, as Pedro pointed out, the original testcase is not portable in some methods, so this patch fixes this issue and some other improvements. Tested on x86_64 ubuntu 20.04.4 and openSUSE Tumbleweed(VERSION_ID="20220425").
2022-04-27x86: VFPCLASSSH is Evex.LLIGJan Beulich7-3/+54
This also was mistakenly flagged as Evex.128.
2022-04-27Fix potential buffer overruns when creating DLLs.Nick Clifton2-15/+53
PR 29006 * pe-dll.c (make_head): Use asprintf to allocate and populate a buffer containing the temporary name. (make_tail, make_one, make_singleton_name_thunk): Likewise. (make_import_fixup_mark, make_import_fixup_entry): Likewise. (make_runtime_pseudo_reloc): Likewise. (pe_create_runtime_relocator_reference): Likewise.
2022-04-27Revert pr29072 lto test changesAlan Modra3-4/+4
Revert commit 65daf5bed6 testsuite changes in ld-plugin/. -z isn't supported for non-ELF targets, and isn't needed since we now prune the exec stack warning (commit 333cd559ba). PR 29072
generated by cgit v1.1 at 2024-11-20 07:19:02 +0000