aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-09-28x86: Print {bad} on invalid broadcast in OP_E_memoryCui,Lili5-79/+104
Don't print broadcast for scalar_mode, and print {bad} for invalid broadcast. gas/ PR binutils/28381 * testsuite/gas/i386/bad-bcast.s: Add a new testcase. * testsuite/gas/i386/bad-bcast.d: Likewise. * testsuite/gas/i386/bad-bcast-intel.d: New. opcodes/ PR binutils/28381 * i386-dis.c (static struct): Add no_broadcast. (OP_E_memory): Mark invalid broadcast with no_broadcast=1 and Print "{bad}"for it. (intel_operand_size): mark invalid broadcast with no_broadcast=1. (OP_XMM): Mark scalar_mode with no_broadcast=1.
2021-09-27gdb: use intrusive_list for linux-nat lwp_listSimon Marchi5-53/+46
Replace the manually maintained linked list of lwp_info objects with intrusive_list. Replace the ALL_LWPS macro with all_lwps, which returns a range. Add all_lwps_safe as well, for use in iterate_over_lwps, which currently iterates in a safe manner. Change-Id: I355313502510acc0103f5eaf2fbde80897d6376c
2021-09-27gdb: add destructor to lwp_infoSimon Marchi2-7/+8
Replace the lwp_free function with a destructor. Make lwp_info non-copyable, since there is now a destructor (we wouldn't want an lwp_info object getting copied and this->arch_private getting deleted twice). Change-Id: I09fcbe967e362566d3a06fed2abca2a9955570fa
2021-09-27gdb: make lwp_info non-PODSimon Marchi2-37/+28
Initialize all fields in the class declaration directly. This opens the door to using intrusive_list, done in the following patch. Change-Id: I38bb27410cd9ebf511d310bb86fe2ea1872c3b05
2021-09-28Automatic date update in version.inGDB Administrator1-1/+1
2021-09-27gdb: don't share aspace/pspace on fork with "detach-on-fork on" and ↵Simon Marchi2-9/+48
"follow-fork-mode child" We found that when handling forks, two inferiors can unexpectedly share their program space and address space. To reproduce: 1. Using a test program that forks... 2. "set follow-fork-mode child" 3. "set detach-on-fork on" (the default) 4. run to a breakpoint somewhere after the fork Step 4 should have created a new inferior: (gdb) info inferiors Num Description Connection Executable 1 <null> /home/smarchi/build/wt/amd/gdb/fork * 2 process 251425 1 (native) /home/smarchi/build/wt/amd/gdb/fork By inspecting the state of GDB, we can see that the two inferiors now share one program space and one address space: Inferior 1: (top-gdb) p inferior_list.m_front.num $2 = 1 (top-gdb) p inferior_list.m_front.aspace $3 = (struct address_space *) 0x5595e2520400 (top-gdb) p inferior_list.m_front.pspace $4 = (struct program_space *) 0x5595e2520440 Inferior 2: (top-gdb) p inferior_list.m_front.next.num $5 = 2 (top-gdb) p inferior_list.m_front.next.aspace $6 = (struct address_space *) 0x5595e2520400 (top-gdb) p inferior_list.m_front.next.pspace $7 = (struct program_space *) 0x5595e2520440 You can then run inferior 1 again and the two inferiors will still erroneously share their spaces, but already at this point this is wrong. The cause of the bad {a,p}space sharing is in follow_fork_inferior. When following the child and detaching from the parent, we just re-use the parent's spaces, rather than cloning them. When we switch back to inferior 1 and run again, we find ourselves with two unrelated inferiors sharing spaces. Fix that by creating new spaces for the parent after having moved them to the child. My initial implementation created new spaces for the child instead. Doing this breaks doing "next" over fork(). When "next" start, we record the symtab of the starting location. When the program stops, we compare that symtab with the symtab the program has stopped at. If the symtab or the line number has changed, we conclude the "next" is done. If we create a new program space for the child and copy the parent's program space to it with clone_program_space, it creates new symtabs for the child as well. When the child stop, but still on the fork() line, GDB thinks the "next" is done because the symtab pointers no longer match. In reality they are two symtab instances that represent the same file. But moving the spaces to the child and creating new spaces for the parent, we avoid this problem. Note that the problem described above happens today with "detach-on-fork off" and "follow-fork-mode child", because we create new spaces for the child. This will have to be addressed later. Test-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is expected to have a location in each inferiors. Without the fix, when the two inferiors erroneously share a program space, GDB reports a single location. Change-Id: Ifea76e14f87b9f7321fc3a766217061190e71c6e
2021-09-27gdb.base/foll-fork.exp: use foreach_with_prefix to handle prefixesSimon Marchi1-84/+81
No behavior change in the test expected, other than in the test names. Change-Id: I111137483858ab0f23138439f2930009779a2b3d
2021-09-27gdb.base/foll-fork.exp: rename variablesSimon Marchi1-20/+20
Rename the variables / parameters used to match the corresponding GDB setting name, I find that easier to follow. Change-Id: Idcbddbbb369279fcf1e808b11a8c478f21b2a946
2021-09-27gdb.base/foll-fork.exp: refactor to restart GDB between each portion of the testSimon Marchi1-63/+81
This test is difficult to follow and modify because the state of GDB is preserved some tests. Add a setup proc, which starts a new GDB and runs to main, and use it in all test procs. Use proc_with_prefix to avoid duplicates. The check_fork_catchpoints proc also seems used to check for follow-fork support by checking if catchpoints are supported. If they are not, it uses "return -code return", which makes its caller return. I find this unnecessary complex, versus just returning a boolean. Modify it to do so. Change-Id: I23e62b204286c5e9c5c86d2727f7d33fb126ed08
2021-09-27gdb.base/foll-fork.exp: remove gating based on target tripletSimon Marchi1-7/+0
It looks like this test has some code to check at runtime the support of fork handling of the target (see check_fork_catchpoints). So, it seems to me that the check based on target triplet at the beginning of the test is not needed. This kind of gating is generally not desirable, because we wouldn't think of updating it when adding fork support to a target. For example, FreeBSD supports fork, but it wasn't listed here. Change-Id: I6b55f2298edae6b37c3681fb8633d8ea1b5aabee
2021-09-27gdb.base/foll-fork.exp: remove DUPLICATEsSimon Marchi1-14/+6
Remove DUPLICATEs, and and at the same time replace two uses of gdb_test_multiple with gdb_test. I don't think using gdb_test_multiple is necessary here. Change-Id: I8dcf097c3364e92d4f0e11f0c0f05dbb88e86742
2021-09-27libctf, lookup: fix bounds of pptrtab lookupNick Alcock4-2/+78
An off-by-one bug in the check for pptrtab lookup meant that we could access the pptrtab past its bounds (*well* past its bounds), particularly if we called ctf_lookup_by_name in a child dict with "*foo" where "foo" is a type that exists in the parent but not the child and no previous lookups by name have been carried out. (Note that "*foo" is not even a valid thing to call ctf_lookup_by_name with: foo * is. Nonetheless, users sometimes do call ctf_lookup_by_name with invalid content, and it should return ECTF_NOTYPE, not crash.) ctf_pptrtab_len, as its name suggests (and as other tests of it in ctf-lookup.c confirm), is one higher than the maximum valid permissible index, so the comparison is wrong. (Test added, which should fail pretty reliably in the presence of this bug on any machine with 4KiB pages.) libctf/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * ctf-lookup.c (ctf_lookup_by_name_internal): Fix pptrtab bounds. * testsuite/libctf-writable/pptrtab-writable-page-deep-lookup.*: New test.
2021-09-27libctf, testsuite: fix various warnings in testsNick Alcock11-18/+28
These warnings are all off by default, but if they do fire you get spurious ERRORs when running make check-libctf. libctf/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * testsuite/libctf-lookup/enum-symbol.c: Remove unused label. * testsuite/libctf-lookup/conflicting-type-syms.c: Remove unused variables. * testsuite/libctf-regression/pptrtab.c: Likewise. * testsuite/libctf-regression/type-add-unnamed-struct.c: Likewise. * testsuite/libctf-writable/pptrtab.c: Likewise. * testsuite/libctf-writable/reserialize-strtab-corruption.c: Likewise. * testsuite/libctf-regression/nonstatic-var-section-ld-r.c: Fix format string. * testsuite/libctf-regression/nonstatic-var-section-ld.c: Likewise. * testsuite/libctf-regression/nonstatic-var-section-ld.lk: Adjust. * testsuite/libctf-writable/symtypetab-nonlinker-writeout.c: Fix initializer.
2021-09-27libctf: fix handling of CTF symtypetab sections emitted by older GCCNick Alcock2-3/+11
Older (pre-upstreaming) GCC emits a function symtypetab section of a format never read by any extant libctf. We can detect such CTF dicts by the lack of the CTF_F_NEWFUNCINFO flag in their header, and we do so when reading in the symtypetab section -- but if the set of symbols with types is sufficiently sparse, even an older GCC will emit a function index section. In NEWFUNCINFO-capable compilers, this section will always be the exact same length as the corresponding function section (each is an array of uint32_t, associated 1:1 with each other). But this is not true for the older compiler, for which the sections are different lengths. We check to see if the function symtypetab section and its index are the same length, but we fail to skip this check when this is not a NEWFUNCINFO dict, and emit a spurious corruption error for a CTF dict we could have perfectly well opened and used. Fix trivial: check the flag (and fix the terrible grammar of the error message at the same time). libctf/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * ctf-open.c (ctf_bufopen_internal): Don't complain about corrupt function index symtypetab sections if this is an old-format function symtypetab section (which should be ignored in any case). Fix bad grammar.
2021-09-27configure: regenerate in all projects that use libtool.m4Nick Alcock18-410/+514
(including sim/, which has no changelog.) bfd/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. binutils/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. gas/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. gprof/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. ld/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. libctf/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. * Makefile.in: Regenerate. opcodes/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate. zlib/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> * configure: Regenerate.
2021-09-27libctf: try several possibilities for linker versioning flagsNick Alcock4-11/+62
Checking for linker versioning by just grepping ld --help output for mentions of --version-script is inadequate now that Solaris 11.4 implements a --version-script with different semantics. Try linking a test program with a small wildcard-using version script with each supported set of flags in turn, to make sure that linker versioning is not only advertised but actually works. The Solaris "GNU-compatible" linker versioning is not quite GNU-compatible enough, but we can work around the differences by generating a new version script that removes the comments from the original (Solaris ld requires #-style comments), and making another version script for libctf-nonbfd in particular which doesn't mention any of the symbols that appear in libctf.la, to avoid Solaris ld introducing corresponding new NOTYPE symbols to match the version script. libctf/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> PR libctf/27967 * configure.ac (VERSION_FLAGS): Replace with... (ac_cv_libctf_version_script): ... this multiple test. (VERSION_FLAGS_NOBFD): Substitute this too. * Makefile.am (libctf_nobfd_la_LDFLAGS): Use it. Split out... (libctf_ldflags_nover): ... non-versioning flags here. (libctf_la_LDFLAGS): Use it. * libctf.ver: Give every symbol not in libctf-nobfd a comment on the same line noting as much.
2021-09-27libtool.m4: fix nm BSD flag detectionNick Alcock2-43/+54
Libtool needs to get BSD-format (or MS-format) output out of the system nm, so that it can scan generated object files for symbol names for -export-symbols-regex support. Some nms need specific flags to turn on BSD-formatted output, so libtool checks for this in its AC_PATH_NM. Unfortunately the code to do this has a pair of interlocking flaws: - it runs the test by doing an nm of /dev/null. Some platforms reasonably refuse to do an nm on a device file, but before now this has only been worked around by assuming that the error message has a specific textual form emitted by Tru64 nm, and that getting this error means this is Tru64 nm and that nm -B would work to produce BSD-format output, even though the test never actually got anything but an error message out of nm -B. This is fixable by nm'ing *nm itself* (since we necessarily have a path to it). - the test is entirely skipped if NM is set in the environment, on the grounds that the user has overridden the test: but the user cannot reasonably be expected to know that libtool wants not only nm but also flags forcing BSD-format output. Worse yet, one such "user" is the top-level Cygnus configure script, which neither tests for nor specifies any BSD-format flags. So platforms needing BSD-format flags always fail to set them when run in a Cygnus tree, breaking -export-symbols-regex on such platforms. Libtool also needs to augment $LD on some platforms, but this is done unconditionally, augmenting whatever the user specified: the nm check should do the same. One wrinkle: if the user has overridden $NM, a path might have been provided: so we use the user-specified path if there was one, and otherwise do the path search as usual. (If the nm specified doesn't work, this might lead to a few extra pointless path searches -- but the test is going to fail anyway, so that's not a problem.) (Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where *that* is a symlink to /usr/bin/nm.) ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> PR libctf/27967 * libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided NM, if there is one. Run nm on itself, not on /dev/null, to avoid errors from nms that refuse to work on non-regular files. Remove other workarounds for this problem. Strip out blank lines from the nm output.
2021-09-27libtool.m4: augment symcode for Solaris 11Nick Alcock2-1/+7
This reports common symbols like GNU nm, via a type code of 'C'. ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> PR libctf/27967 * libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for Solaris 11.
2021-09-27libctf: link against libiberty before linking in libbfd or libctf-nobfdNick Alcock3-2/+18
This ensures that the CTF_LIBADD, which always contains at least this when doing a shared link: -L`pwd`/../libiberty/pic -liberty appears in the link line before any requirements pulled in by libbfd.la, which include -liberty but because it is install-time do not include the -L`pwd`/../libiberty/pic portion (in an indirect dep like this, the path comes from the libbfd.la file, and is an install path). libiberty also appears after libbfd in the link line by virtue of libctf-nobfd.la, because libctf-nobfd has to follow libbfd in the link line, and that needs symbols from libiberty too. Without this, an installed liberty might well be pulled in by libbfd, and if --enable-install-libiberty is not specified this libiberty might be completely incompatible with what is being installed and break either or boht of libbfd and libctf. (The specific problem observed here is that bsearch_r was not present, but other problems might easily be observed in future too.) Because ld links against libctf, this has a tendency to break the system linker at install time too, if installing with --prefix=/usr. That's quite unpleasant to recover from. libctf/ChangeLog 2021-09-27 Nick Alcock <nick.alcock@oracle.com> PR libctf/27360 * Makefile.am (libctf_la_LIBADD): Link against libiberty before pulling in libbfd.la or pulling in libctf-nobfd.la. * Makefile.in: Regenerate.
2021-09-27[gdb/build] Fix build with g++-4.8Tom de Vries1-2/+6
When building g++-4.8, we run into: ... src/gdb/dwarf2/read.c:919:5: error: multiple fields in union \ 'partial_die_info::<anonymous union>' initialized ... This is due to: ... union { struct { CORE_ADDR lowpc = 0; CORE_ADDR highpc = 0; }; ULONGEST ranges_offset; }; ... The error looks incorrect, given that only one union member is initialized, and does not reproduce with newer g++. Nevertheless, work around this by moving the initialization to a constructor. [ I considered just removing the initialization, with the idea that access should be guarded by has_pc_info, but I ran into one failure in the testsuite, for gdb.base/check-psymtab.exp due to add_partial_symbol using lowpc without checking has_pc_info. ] Tested on x86_64-linux.
2021-09-27gdb: add setting to disable reading source code filesAndrew Burgess7-3/+179
In some situations it is possible that a user might not want GDB to try and access source code files, for example, the source code might be stored on a slow to access network file system. It is almost certainly possible that using some combination of 'set directories' and/or 'set substitute-path' a user can trick GDB into being unable to find the source files, but this feels like a rather crude way to solve the problem. In this commit a new option is add that stops GDB from opening and reading the source files. A user can run with source code reading disabled if this is required, then re-enable later if they decide that they now want to view the source code.
2021-09-27gdb: remove duplicate cmd_list_element declarationsAndrew Burgess2-104/+33
For some reason we have two locations where cmd_list_elements are declared, cli/cli-cmds.h and gdbcmd.h. Worse still there is duplication between these two locations. In this commit I have moved all of the cmd_list_element declarations from gdbcmd.h into cli/cli-cmds.h and removed the duplicates. There should be no user visible changes after this commit.
2021-09-27gdb: prevent an assertion when computing the frame_id for an inline frameAndrew Burgess5-9/+344
I ran into this assertion while GDB was trying to unwind the stack: gdb/inline-frame.c:173: internal-error: void inline_frame_this_id(frame_info*, void**, frame_id*): Assertion `frame_id_p (*this_id)' failed. That is, when building the frame_id for an inline frame, GDB asks for the frame_id of the previous frame. Unfortunately, no valid frame_id was returned for the previous frame, and so the assertion triggers. What is happening is this, I had a stack that looked something like this (the arrows '->' point from caller to callee): normal_frame -> inline_frame However, for whatever reason (e.g. broken debug information, or corrupted stack contents in the inferior), when GDB tries to unwind "normal_frame", it ends up getting back effectively the same frame, thus the call stack looks like this to GDB: .-> normal_frame -> inline_frame | | '-----' Given such a situation we would expect GDB to terminate the stack with an error like this: Backtrace stopped: previous frame identical to this frame (corrupt stack?) However, the inline_frame causes a problem, and here's why: When unwinding we start from the sentinel frame and call get_prev_frame. We eventually end up in get_prev_frame_if_no_cycle, in here we create a raw frame, and as this is frame #0 we immediately return. However, eventually we will try to unwind the stack further. When we do this we inevitably needing to know the frame_id for frame #0, and so, eventually, we end up in compute_frame_id. In compute_frame_id we first find the right unwinder for this frame, in our case (i.e. for inline_frame) the $pc is within the function normal_frame, but also within a block associated with the inlined function inline_frame, as such the inline frame unwinder claims this frame. Back in compute_frame_id we next compute the frame_id, for our inline_frame this means a call to inline_frame_this_id. The ID of an inline frame is based on the id of the previous frame, so from inline_frame_this_id we call get_prev_frame_always, this eventually calls get_prev_frame_if_no_cycle again, which creates another raw frame and calls compute_frame_id (for frames other than frame 0 we immediately compute the frame_id). In compute_frame_id we again identify the correct unwinder for this frame. Our $pc is unchanged, however, the fact that the next frame is of type INLINE_FRAME prevents the inline frame unwinder from claiming this frame again, and so, the standard DWARF frame unwinder claims normal_frame. We return to compute_frame_id and call the standard DWARF function to build the frame_id for normal_frame. With the frame_id of normal_frame figured out we return to compute_frame_id, and then to get_prev_frame_if_no_cycle, where we add the ID for normal_frame into the frame_id cache, and return the frame back to inline_frame_this_id. From inline_frame_this_id we build a frame_id for inline_frame and return to compute_frame_id, and then to get_prev_frame_if_no_cycle, which adds the frame_id for inline_frame into the frame_id cache. So far, so good. However, as we are trying to unwind the complete stack, we eventually ask for the previous frame of normal_frame, remember, at this point GDB doesn't know the stack is corrupted (with a cycle), GDB still needs to figure that out. So, we eventually end up in get_prev_frame_if_no_cycle where we create a raw frame and call compute_frame_id, remember, this is for the frame before normal_frame. The first task for compute_frame_id is to find the unwinder for this frame, so all of the frame sniffers are tried in order, this includes the inline frame sniffer. The inline frame sniffer asks for the $pc, this request is sent up the stack to normal_frame, which, due to its cyclic behaviour, tells GDB that the $pc in the previous frame was the same as the $pc in normal_frame. GDB spots that this $pc corresponds to both the function normal_frame and also the inline function inline_frame. As the next frame is not an INLINE_FRAME then GDB figures that we have not yet built a frame to cover inline_frame, and so the inline sniffer claims this new frame. Our stack is now looking like this: inline_frame -> normal_frame -> inline_frame But, we have not yet computed the frame id for the outer most (on the left) inline_frame. After the frame sniffer has claimed the inline frame GDB returns to compute_frame_id and calls inline_frame_this_id. In here GDB calls get_prev_frame_always, which eventually ends up in get_prev_frame_if_no_cycle again, where we create a raw frame and call compute_frame_id. Just like before, compute_frame_id tries to find an unwinder for this new frame, it sees that the $pc is within both normal_frame and inline_frame, but the next frame is, again, an INLINE_FRAME, so, just like before the standard DWARF unwinder claims this frame. Back in compute_frame_id we again call the standard DWARF function to build the frame_id for this new copy of normal_frame. At this point the stack looks like this: normal_frame -> inline_frame -> normal_frame -> inline_frame After compute_frame_id we return to get_prev_frame_if_no_cycle, where we try to add the frame_id for the new normal_frame into the frame_id cache, however, unlike before, we fail to add this frame_id as it is a duplicate of the previous normal_frame frame_id. Having found a duplicate get_prev_frame_if_no_cycle unlinks the new frame from the stack, and returns nullptr, the stack now looks like this: inline_frame -> normal_frame -> inline_frame The nullptr result from get_prev_frame_if_no_cycle is fed back to inline_frame_this_id, which forwards this to get_frame_id, which immediately returns null_frame_id. As null_frame_id is not considered a valid frame_id, this is what triggers the assertion. In summary then: - inline_frame_this_id currently assumes that as the inline frame exists, we will always get a valid frame back from get_prev_frame_always, - get_prev_frame_if_no_cycle currently assumes that it is safe to return nullptr when it sees a cycle. Notice that in frame.c:compute_frame_id, this code: fi->this_id.value = outer_frame_id; fi->unwind->this_id (fi, &fi->prologue_cache, &fi->this_id.value); gdb_assert (frame_id_p (fi->this_id.value)); The assertion makes it clear that the this_id function must always return a valid frame_id (e.g. null_frame_id is not a valid return value), and similarly in inline_frame.c:inline_frame_this_id this code: *this_id = get_frame_id (get_prev_frame_always (this_frame)); /* snip comment */ gdb_assert (frame_id_p (*this_id)); Makes it clear that every inline frame expects to be able to get a previous frame, which will have a valid frame_id. As I have discussed above, these assumptions don't currently hold in all cases. One possibility would be to move the call to get_prev_frame_always forward from inline_frame_this_id to inline_frame_sniffer, however, this falls foul of (in frame.c:frame_cleanup_after_sniffer) this assertion: /* No sniffer should extend the frame chain; sniff based on what is already certain. */ gdb_assert (!frame->prev_p); This assert prohibits any sniffer from trying to get the previous frame, as getting the previous frame is likely to depend on the next frame, I can understand why this assertion is a good thing, and I'm in no rush to alter this rule. The solution proposed here takes onboard feedback from both Pedro, and Simon (see the links below). The get_prev_frame_if_no_cycle function is renamed to get_prev_frame_maybe_check_cycle, and will now not do cycle detection for inline frames, even when we spot a duplicate frame it is still returned. This is fine, as, if the normal frame has a duplicate frame-id then the inline frame will also have a duplicate frame-id. And so, when we reject the inline frame, the duplicate normal frame, which is previous to the inline frame, will also be rejected. In inline-frame.c the call to get_prev_frame_always is no longer nested inside the call to get_frame_id. There are reasons why get_prev_frame_always can return nullptr, for example, if there is a memory error while trying to get the previous frame, if this should happen then we now give a more informative error message. Historical Links: Patch v2: https://sourceware.org/pipermail/gdb-patches/2021-June/180208.html Feedback: https://sourceware.org/pipermail/gdb-patches/2021-July/180651.html https://sourceware.org/pipermail/gdb-patches/2021-July/180663.html Patch v3: https://sourceware.org/pipermail/gdb-patches/2021-July/181029.html Feedback: https://sourceware.org/pipermail/gdb-patches/2021-July/181035.html Additional input: https://sourceware.org/pipermail/gdb-patches/2021-September/182040.html
2021-09-27[gdb/testsuite] Fix gdb.base/dcache-flush.expTom de Vries1-2/+2
When running test-case gdb.base/dcache-flush.exp on ubuntu 18.04.5, I run into: ... (gdb) PASS: gdb.base/dcache-flush.exp: p var2 info dcache^M Dcache 4096 lines of 64 bytes each.^M Contains data for Thread 0x7ffff7fc6b80 (LWP 3551)^M Line 0: address 0x7fffffffd4c0 [47 hits]^M Line 1: address 0x7fffffffd500 [31 hits]^M Line 2: address 0x7fffffffd5c0 [7 hits]^M Cache state: 3 active lines, 85 hits^M (gdb) FAIL: gdb.base/dcache-flush.exp: check dcache before flushing ... The regexp expects "Contains data for process $decimal". This is another case of thread_db_target::pid_to_str being used. Fix this by updating the regexp. Tested on x86_64-linux.
2021-09-27[gdb/testsuite] Test sw watchpoint in ↵Tom de Vries1-11/+30
gdb.threads/process-dies-while-detaching.exp The test-case gdb.threads/process-dies-while-detaching.exp takes about 20s when using hw watchpoints, but when forcing sw watchpoints (using the patch mentioned in PR28375#c0), the test-case takes instead 3m14s. Also, it show a FAIL: ... (gdb) continue^M Continuing.^M Cannot find user-level thread for LWP 10324: generic error^M (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue ... for which PR28375 was filed. Modify the test-case to: - add the hw/sw axis to the watchpoint testing, to ensure that we observe the sw watchpoint behaviour also on can-use-hw-watchpoints architectures. - skip the hw breakpoint testing if not supported - set the sw watchpoint later to avoid making the test too slow. This still triggers the same PR, but now takes just 24s. This patch adds a KFAIL for PR28375. Tested on x86_64-linux.
2021-09-26gdb: fix indentation in gdbtypes.cSimon Marchi1-1/+1
Change-Id: I7bfbb9d349a1f474256800c45e28fe3b1de08771
2021-09-27Automatic date update in version.inGDB Administrator1-1/+1
2021-09-26Automatic date update in version.inGDB Administrator1-1/+1
2021-09-25PowerPC: Enable mfppr mfppr32, mtppr and mtppr32 extended mnemonics on POWER5Peter Bergner8-12/+39
SPR 896 and the mfppr mfppr32, mtppr and mtppr32 extended mnemonics were added in ISA 2.03, so enable them on POWER5 and later. opcodes/ * ppc-opc.c (powerpc_opcodes) <mfppr, mfppr32, mtppr, mtppr32>: Enable on POWER5 and later. gas/ * testsuite/gas/ppc/power5.s: New test. * testsuite/gas/ppc/power5.d: Likewise. * testsuite/gas/ppc/ppc.exp: Run it. * testsuite/gas/ppc/power7.s: Remove tests for mfppr, mfppr32, mtppr and mtppr32. * testsuite/gas/ppc/power7.d: Likewise.
2021-09-25[gdb/testsuite] Minimize gdb restartsTom de Vries68-115/+45
Minimize gdb restarts, applying the following rules: - don't use prepare_for_testing unless necessary - don't use clean_restart unless necessary Also, if possible, replace build_for_executable + clean_restart with prepare_for_testing for brevity. Touches 68 test-cases. Tested on x86_64-linux.
2021-09-25PR28346, segfault attempting to disassemble raw binaryAlan Modra1-1/+2
Don't attempt to access elf_section_data for non-ELF sections. PR 28346 * elf32-xtensa.c (xtensa_read_table_entries): Return zero entries for non-ELF.
2021-09-25Automatic date update in version.inGDB Administrator1-1/+1
2021-09-24gas/testsuite/ld-elf/dwarf2-21.d: Pass -WHans-Peter Nilsson1-1/+1
Required for the expected "CU:" to be emitted for long source-paths. See binutils/dwarf.c: if (do_wide || strlen (directory) < 76) printf (_("CU: %s/%s:\n"), directory, file_table[0].name); else printf ("%s:\n", file_table[0].name); See also commit 5f410aa50ce2c, "testsuite/ld-elf/pr26936.d: Pass -W." gas/ChangeLog: * testsuite/ld-elf/dwarf2-21.d: Pass -W.
2021-09-24gdb: change thread_info::name to unique_xmalloc_ptr, add helper functionSimon Marchi6-30/+57
This started out as changing thread_info::name to a unique_xmalloc_ptr. That showed that almost all users of that field had the same logic to get a thread's name: use thread_info::name if non-nullptr, else ask the target. Factor out this logic in a new thread_name free function. Make the field private (rename to m_name) and add some accessors. Change-Id: Iebdd95f4cd21fbefc505249bd1d05befc466a2fc
2021-09-24Move value_true to value.hTom Tromey8-34/+20
I noticed that value_true is declared in language.h and defined in language.c. However, as part of the value API, I think it would be better in one of those files. And, because it is very short, I changed it to be an inline function in value.h. I've also removed a comment from the implementation, on the basis that it seems obsolete -- if the change it suggests was needed, it probably would have been done by now; and if it is needed in the future, odds are it would be done differently anyway. Finally, this patch also changes value_true and value_logical_not to return a bool, and updates some uses.
2021-09-24Make dcache multi-target-safePedro Alves1-3/+11
By inspection, I noticed that this code in dcache.c is not multi-target-aware: /* If this is a different inferior from what we've recorded, flush the cache. */ if (inferior_ptid != dcache->ptid) This doesn't take into account that threads of different targets may have the same ptid. Fixed by also storing/comparing the process_stratum_target. Tested on x86-64-linux-gnu, native and gdbserver. Change-Id: I4d9d74052c696b72d28cb1c77b697b911725c8d3
2021-09-24Fix 'FAIL: gdb.perf/disassemble.exp: python Disassemble().run()'Pedro Alves1-3/+4
We currently have one FAIL while running "make check-perf": PerfTest::assemble, run ... python Disassemble().run() Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 64, in run self.warm_up() File "<string>", line 25, in warm_up gdb.error: No symbol "ada_evaluate_subexp" in current context. Error while executing Python code. (gdb) FAIL: gdb.perf/disassemble.exp: python Disassemble().run() ... The gdb.perf/disassemble.exp testcase debugs GDB with itself, runs to main, and then disassembles a few GDB functions. The problem is that most(!) functions it is trying to disassemble are now gone... This commit fixes the issue by simply picking some other functions to disassemble. It would perhaps be better to come up with some test program to disassemble, one that would stay the same throughout the years, instead of disassembling GDB itself. I don't know why that wasn't done to begin with. I'll have to leave that for another rainy day, though. gdb/testsuite/ yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.perf/disassemble.py (Disassemble::warm_up): Disassemble evaluate_subexp_do_call instead of ada_evaluate_subexp. (Disassemble::warm_up): Disassemble "captured_main", "run_inferior_call" and "update_global_location_list" instead of "evaluate_subexp_standard" and "c_parse_internal". Change-Id: I89d1cca89ce2e495dea5096e439685739cc0d3df
2021-09-24Fix all PATH problems in testsuite/gdb.perf/Pedro Alves1-3/+9
Currently "make check-perf" triggers ~40 PATH messages in gdb.sum: ... PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build/gdb/../../src/gdb/testsuite/gdb.perf/lib")) PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ()) ... This commit fixes them. E.g. before/after gdb.sum diff: -PASS: gdb.perf/backtrace.exp: python import os, sys -PASS: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib")) -PATH: gdb.perf/backtrace.exp: python sys.path.insert(0, os.path.abspath("/home/pedro/rocm/gdb/build-master/gdb/../../src/gdb/testsuite/gdb.perf/lib")) -PASS: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ()) -PATH: gdb.perf/backtrace.exp: python exec (open ('/home/pedro/rocm/gdb/build-master/gdb/testsuite/outputs/gdb.perf/backtrace/backtrace.py').read ()) +PASS: gdb.perf/backtrace.exp: setup perftest: python import os, sys +PASS: gdb.perf/backtrace.exp: setup perftest: python sys.path.insert(0, os.path.abspath("${srcdir}/gdb.perf/lib")) +PASS: gdb.perf/backtrace.exp: setup perftest: python exec (open ('${srcdir}/gdb.perf/backtrace.py').read ()) gdb/testsuite/ yyyy-mm-dd Pedro Alves <pedro@palves.net> * lib/perftest.exp (PerfTest::_setup_perftest): Use with_test_prefix. Add explicit test names to python invocations, with "$srcdir" not expanded. Change-Id: I50a31b04b7abdea754139509e4a34ae9263118a4
2021-09-24Fix all DUPLICATE problems in testsuite/gdb.perf/Pedro Alves1-3/+6
Currently running "make check-perf" shows: ... # of duplicate test names 6008 ... All those duplicate test names come from gdb.perf/skip-command.exp. This commit fixes them, using with_test_prefix. gdb/testsuite/ yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.perf/skip-command.exp (run_skip_bench): Wrap each for iteration in with_test_prefix. Change-Id: I38501cf70bc6b60306ee7228996ee7bcd858dc1b
2021-09-24Fix handling of DW_AT_data_bit_offsetTom Tromey3-17/+114
A newer version of GCC will now emit member locations using just DW_AT_data_bit_offset, like: <3><14fe>: Abbrev Number: 1 (DW_TAG_member) <14ff> DW_AT_name : (indirect string, offset: 0x215e): nb_bytes <1503> DW_AT_decl_file : 1 <1503> DW_AT_decl_line : 10 <1504> DW_AT_decl_column : 7 <1505> DW_AT_type : <0x150b> <1509> DW_AT_bit_size : 31 <150a> DW_AT_data_bit_offset: 64 whereas earlier versions would emit something like: <3><164f>: Abbrev Number: 7 (DW_TAG_member) <1650> DW_AT_name : (indirect string, offset: 0x218d): nb_bytes <1654> DW_AT_decl_file : 1 <1655> DW_AT_decl_line : 10 <1656> DW_AT_decl_column : 7 <1657> DW_AT_type : <0x165f> <165b> DW_AT_byte_size : 4 <165c> DW_AT_bit_size : 31 <165d> DW_AT_bit_offset : 1 <165e> DW_AT_data_member_location: 8 That is, DW_AT_data_member_location is not emitted any more. This is a change due to the switch to DWARF 5 by default. This change pointed out an existing bug in gdb, namely that the attr_to_dynamic_prop depends on the presence of DW_AT_data_member_location. This patch moves the handling of DW_AT_data_bit_offset into handle_data_member_location, and updates attr_to_dynamic_prop to handle this new case. A new test case is included. This test fails with GCC 11, but passes with an earlier version of GCC.
2021-09-24[gdb/testsuite] Don't leave gdb instance running after function_rangeTom de Vries2-3/+9
A typical dwarf assembly test-case start like this: ... standard_testfile .c -debug.S set asm_file [standard_output_file $srcfile2] Dwarf::assemble $asm_file { ... } if { [prepare_for_testing "failed to prepare" ${testfile} \ [list $srcfile $asm_file] {nodebug}] } { return -1 } ... When accidentally using build_for_executable instead of prepare_for_testing (or intentionally using it but forgetting to add clean_restart $binfile or some such) the mistake may not be caught, because another gdb instance is still running, and we may silently end up testing compiler-generated DWARF. This can be caused by something relatively obvious, like an earlier prepare_for_testing or clean_restart, but also by something more obscure like function_range, which may even be triggered by dwarf assembly like this: ... {MACRO_AT_func {main}} ... Fix this by calling gdb_exit at the end of function_range. Also fix the fallout of that in test-case gdb.dwarf2/dw2-bad-elf.exp, where a get_sizeof call used the gdb instance left lingering by function_range. [ A better and more complete fix would add a new proc get_exec_info, that would be called at the start of the dwarf assembly body: ... Dwarf::assemble $asm_file { get_exec_info {main foo} {int void*} ... that would: - do a prepare_for_testing with $srcfile (roughtly equivalent to what MACRO_AT_func does, - call function_range for all functions main and foo, without starting a new gdb instance - set corresponding variables at the call-site: main_start, main_len, main_end, foo_start, foo_len, foo_end. - get size for types int and void* - set corresponding variables at the call-site: int_size, void_ptr_size. - do a gdb_exit. ] Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Use pie instead of -fpie/-pieTom de Vries2-2/+4
I noticed two test-cases where -fpie is used. Using the canonical pie option will usually get one -fPIE instead. That choice is justified here in gdb_compile: ... # For safety, use fPIE rather than fpie. On AArch64, m68k, PowerPC # and SPARC, fpie can cause compile errors due to the GOT exceeding # a maximum size. On other architectures the two flags are # identical (see the GCC manual). Note Debian9 and Ubuntu16.10 # onwards default GCC to using fPIE. If you do require fpie, then # it can be set using the pie_flag. set flag "additional_flags=-fPIE" ... There is no indication that using -fpie rather than -fPIE is on purpose, so use pie instead. Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Factor out dump_info in gdb.testsuite/dump-system-info.expTom de Vries1-26/+16
Factor out new proc dump_info in test-case gdb.testsuite/dump-system-info.exp, and in the process: - fix a few typos - remove unnecessary "test -r /proc/cpuinfo" Tested on x86_64-linux. Co-Authored-By: Pedro Alves <pedro@palves.net>
2021-09-24gdb/testsuite: Make it possible to use TCL variables in DWARF assembler loclistsPedro Alves1-0/+4
It is currently not possible to use variables in locations lists. For example, with: diff --git a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp index 6b4f5c8cbb8..cdbf948619f 100644 --- a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp +++ b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp @@ -30,6 +30,8 @@ if {![dwarf2_support]} { return 0 } +set myconst 0x123456 + # Test with 32-bit and 64-bit DWARF. foreach_with_prefix is_64 {false true} { if { $is_64 } { @@ -49,6 +51,7 @@ foreach_with_prefix is_64 {false true} { global func1_addr func1_len global func2_addr func2_len global is_64 + global myconst # The CU uses the DW_FORM_loclistx form to refer to the .debug_loclists # section. @@ -107,7 +110,7 @@ foreach_with_prefix is_64 {false true} { list_ { # When in func1. start_length $func1_addr $func1_len { - DW_OP_constu 0x123456 + DW_OP_constu $myconst DW_OP_stack_value } we get: $ make check TESTS="*/loclists-multiple-cus.exp" ... gdb compile failed, build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S: Assembler messages: build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S:78: Error: leb128 operand is an undefined symbol: $myconst ... That means $myconst was copied literally to the generated assembly file. This patch fixes it, by running subst on the location list body, in the context of the caller. The fix is applied to both Dwarf::loclists::table::list_::start_length and Dwarf::loclists::table::list_::start_end. Reported-by: Zoran Zaric <Zoran.Zaric@amd.com> Change-Id: I615a64431857242d9f477d5699e3732df1b31322
2021-09-24[gdb/testsuite] Fix DUPLICATEs in gdb.dwarf2/implptr-64bit.expTom de Vries1-4/+18
When running test-case gdb.dwarf2/implptr-64bit.exp with target board unix/-m32, I noticed: ... DUPLICATE: gdb.dwarf2/implptr-64bit.exp: failed to prepare ... Fix this by using with_test_prefix. Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Fix DUPLICATEs gdb.dwarf2/dw2-is-stmt.expTom de Vries1-46/+54
Fix these DUPLICATEs by using with_test_prefix: ... DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 1 DUPLICATE: gdb.dwarf2/dw2-is-stmt.exp: ensure we saw a valid line pattern, 2 ... Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Fix set $var val in gdb.dwarf2/dw2-is-stmt.expTom de Vries1-2/+2
When doing a testrun with: ... $ make check RUNTESTFLAGS=$(cd $src/gdb/testsuite/; echo gdb.dwarf2/*.exp) ... I ran into: ... ERROR: tcl error sourcing gdb.dwarf2/dw2-is-stmt.exp. ERROR: expected integer but got "dw2-abs-hi-pc-world.c" while executing "incr i" ... The variable i is set in gdb.dwarf2/dw2-abs-hi-pc.exp, and leaks to gdb.dwarf2/dw2-is-stmt.exp. It's not removed by gdb_cleanup_globals because i is set as global variable by runtest.exp, which does: ... for { set i 0 } { $i < $argc } { incr i } { ... at toplevel but forgets to unset the variable. Fix this by removing '$' in front of the variable name when doing set: ... -set $i 0 +set i 0 ... Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Fix DUPLICATE in gdb.base/load-command.expTom de Vries1-5/+9
Fix this duplicate: ... DUPLICATE: gdb.base/load-command.exp: check initial value of the_variable ... by using with_test_prefix. Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Use pie/nopie instead of ldflags=-pie/-no-pieTom de Vries2-2/+2
I noticed two test-case that use ldflags=-pie and ldflags-no-pie, instead of the canonical pie and nopie options, which would typically also add additional_flags=-fPIE respectively additional_flags=-fno-pie. There is no indication that this is on purpose, so replace these with pie and nopie. Tested on x86_64-linux.
2021-09-24[gdb/testsuite] Add gdb.testsuite/dump-system-info.expTom de Vries1-0/+48
When interpreting the testsuite results, it's often relevant what kind of machine the testsuite ran on. On a local machine one can just do /proc/cpuinfo, but in case of running tests using a remote system that distributes test runs to other remote systems that are not directly accessible, that's not possible. Fix this by dumping /proc/cpuinfo into the gdb.log, as well as lsb_release -a and uname -a. We could do this at the start of each test run, by putting it into unix.exp or some such. However, this might be too verbose, so we choose to put it into its own test-case, such that it get triggered in a full testrun, but not when running one or a subset of tests. We put the test-case into the gdb.testsuite directory, which is currently the only place in the testsuite where we do not test gdb. [ Though perhaps this could be put into a new gdb.info directory, since the test-case doesn't actually test the testsuite. ] Tested on x86_64-linux.
generated by cgit v1.1 at 2024-11-23 05:22:46 +0000