aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-01-22gnulib: update to 776af40e0users/simark/update-gnulibPaul E. Murphy399-4531/+7191
This fixes PR27184, a failure to compile gdb due to cdefs.h being out of sync with glibc on ppc64le targets which are compiled with -mabi=ieeelongdouble and glibc 2.32. Likewise, update usage of _GL_ATTRIBUTE_FORMAT_PRINTF to _GL_ATTRIBUTE_FORMAT_PRINTF_STANDARD. Likewise, disable newly added rpl_free gnulib api in gdbserver support libraries. Likewise, undefine read/write macros before redefining them on mingw targets. Likewise, wrap C++ usage of free with GNULIB_NAMESPACE namespace as needed. Change-Id: I86517613c0d8ac8f5ea45bbc4ebe2b54a3aef29f
2021-01-22gdb: add new version styleAndrew Burgess10-12/+74
This commit adds a new 'version' style, which replaces the hard coded styling currently used for GDB's version string. GDB's version number is displayed: 1. In the output of 'show version', and 2. When GDB starts up (without the --quiet option). This new style can only ever affect the first of these two cases as the second case is printed before GDB has processed any initialization files, or processed any GDB commands passed on the command line. However, because the first case exists I think this commit makes sense, it means the style is no longer hard coded into GDB, and we can add some tests that the style can be enabled/disabled correctly. This commit is an alternative to a patch Tom posted here: https://sourceware.org/pipermail/gdb-patches/2020-June/169820.html I've used the style name 'version' instead of 'startup' to reflect what the style is actually used for. If other parts of the startup text end up being highlighted I imagine they would get their own styles based on what is being highlighted. I feel this is more inline with the other style names that are already in use within GDB. I also decoupled adding this style from the idea of startup options, and the possibility of auto-saving startup options. Those ideas can be explored in later patches. This commit should probably be considered only a partial solution to issue PR cli/25956. The colours of the style are no longer hard coded, however, it is still impossible to change the styling of the version string displayed during startup, so in one sense, the styling of that string is still "hard coded". A later patch will hopefully extend GDB to allow it to adjust the version styling before the initial version string is printed. gdb/ChangeLog: PR cli/25956 * cli/cli-style.c: Add 'cli/cli-setshow.h' include. (version_style): Define. (cli_style_option::cli_style_option): Add intensity parameter, and use as appropriate. (_initialize_cli_style): Register version style set/show commands. * cli/cli-style.h (cli_style_option): Add intensity parameter. (version_style): Declare. * top.c (print_gdb_version): Use version_stype, and styled_string to print the GDB version string. gdb/doc/ChangeLog: PR cli/25956 * gdb.texinfo (Output Styling): Document version style. gdb/testsuite/ChangeLog: PR cli/25956 * gdb.base/style.exp (run_style_tests): Add version string test. (test_startup_version_string): Use version style name. * lib/gdb-utils.exp (style): Handle version style name.
2021-01-22gdb: don't print escape characters when a style is disabledAndrew Burgess4-208/+315
While working on another patch I noticed that if I disable a single style with, for example: set style filename background none set style filename foreground none set style filename intensity normal Then in some places escape characters are still injected into the output stream. This is a bit of an edge case, and I can't think when this would actually cause problems, but it still felt like a bit of an annoyance. One place where this does impact is in testing, where it becomes harder to write tight test patterns if it is not obvious when GDB will decide to inject escape sequences. It's especially annoying because depending on how something is printed then GDB might, or might not, add escape characters. So this would not add escape characters if the filename style was disabled: fprintf_filtered (file, "%ps", styled_string (file_name_style.style (), "This is a test")); But this would add escape characters: fprintf_styled (file, file_name_style.style (), "%s", "This is a test"); I tracked this down to some calls to set_output_style in utils.c. Currently some calls to set_output_style (in utils.c) are guarded like this: if (!STYLE.is_default ()) set_output_style (stream, STYLE); But some calls are not. It is the calls that are NOT guarded that cause the extra escape sequences to be emitted. My initial proposal to resolve this issue was simply to ensure that all calls to set_output_style were guarded. The patch I posted for this can be found here: https://sourceware.org/pipermail/gdb-patches/2021-January/175096.html The feedback on this proposal was that it might be better to guard against the escape sequences being emitted at a later lever, right down at emit_style_escape. So this is what this version does. In emit_style_escape we already track the currently applied style, so if the style we are being asked to switch to is the same as the currently applied style then no escape sequence needs to be emitted. Making this change immediately exposed some issues in fputs_maybe_filtered related to line wrapping. The best place to start to understand what's going on with the styling and wrapping is look at the test: gdb.base/style.exp: all styles enabled: frame when width=20 If you run this test and then examine the output in an editor so the escape sequences can be seen you'll see the duplicate escape sequences that are emitted before this patch, the compare to after this patch you'll see the set of escape sequences should be the minimum required. In order to test these changes I have rewritten the gdb.base/style.exp test script. The core of the script is now run multiple times. The first time the test is run things are as they were before, all styles are on. After that the test is rerun multiple times. Each time through a single style is disabled using the 3 explicit set calls listed above. I then repeat all the tests, however, I arrange so that the patterns for the disabled style now require no escape sequences. gdb/ChangeLog: * utils.c (emit_style_escape): Only emit an escape sequence if the requested style is different than the current applied style. (fputs_maybe_filtered): Adjust the juggling of the wrap_style, and current applied_style. (fputs_styled): Remove is_default check. (fputs_styled_unfiltered): Likewise. (vfprintf_styled_no_gdbfmt): Likewise. gdb/testsuite/ChangeLog: * gdb.base/style.exp (limited_style): New proc. (clean_restart_and_disable): New proc. (run_style_tests): New proc. Most of the old tests from this file are now in this proc. (test_startup_version_string): New proc. Reamining test from the old file is in this proc.
2021-01-22gdb/doc: don't rely on @menu item within the docsAndrew Burgess2-11/+20
The node 'Auto-loading extensions' currently relies on a @menu item to provide a set of cross-references to different parts of the manual. Additionally the menu is placed part way through the node and the text prior to the menu seems (to me) to assume that the menu will be formatted into the document. This is a bad idea as the menus are not always part of the final document (e.g. pdf output does not include the menu), when compared to the info page the pdf version of this node is less helpful as it lacks proper cross references. Menus should always be placed at the end of a node. In this commit I rewrite a paragraph to add extra cross references inline within the text. I then move the menu to the end of the node. gdb/doc/ChangeLog: * gdb.texinfo (Auto-loading extensions): Add additional cross references and move @menu to the end of the node.
2021-01-22gdb: add remote_debug_printfSimon Marchi8-151/+113
This is the next in the new-style debug macro series. For this one, I decided to omit the function name from the "Sending packet" / "Packet received" kind of prints, just because it's not very useful in that context and hinders readability more than anything else. This is completely arbitrary. This is with: [remote] putpkt_binary: Sending packet: $qTStatus#49... [remote] getpkt_or_notif_sane_1: Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes:: and without: [remote] Sending packet: $qTStatus#49... [remote] Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes:: A difference is that previously, the query packet and its reply would be printed on the same line, like this: Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes:: Now, they are printed on two lines, since each remote_debug_printf{,_nofunc} prints its own complete message including an end of line. It's probably a matter of taste, but I prefer the two-line version, it's easier to follow, especially when the query packet is long. As a result, lib/range-stepping-support.exp needs to be updated, as it currently expects the vCont packet and the reply to be on the same line. I think it's sufficient in that context to just expect the vCont packet and not the reply, since the goal is just to count how many vCont;r GDB sends. gdb/ChangeLog: * remote.h (remote_debug_printf): New. (remote_debug_printf_nofunc): New. (REMOTE_SCOPED_DEBUG_ENTER_EXIT): New. * remote.c: Use above macros throughout file. gdbsupport/ChangeLog: * common-debug.h (debug_prefixed_printf_cond_nofunc): New. * common-debug.c (debug_prefixed_vprintf): Handle a nullptr func. gdb/testsuite/ChangeLog: * lib/range-stepping-support.exp (exec_cmd_expect_vCont_count): Adjust to "set debug remote" changes. Change-Id: Ica6dead50d3f82e855c7d763f707cef74bed9fee
2021-01-22gdb: change remote_debug to boolSimon Marchi3-10/+17
As far as I can see, there are no more spots looking for a remote_debug other than true/false. If we ever want to revert to an int, we can always change it back later, but this makes things simpler for now. gdb/ChangeLog: * remote.h (remote_debug): Change to bool. * remote.c (remote_debug): Change to bool. (_initialize_remote): Adjust. Change-Id: I21aac5b4cff9dc4f75c8efaf47c23583ecabd2a6
2021-01-22gdb: move remote_debug to remote.{h,c}Simon Marchi6-7/+17
remote_debug is currently declared in target.h and defined in top.c. Move them to remote.h and remote.c. Include remote.h in remote-sim.c, as it uses remote_debug. gdb/ChangeLog: * target.h (remote_debug): Move to... * remote.h (remote_debug): ... here. * top.c (remote_debug): Move to... * remote.c (remote_debug): ... here. * remote-sim.c: Include remote.h. Change-Id: Iae632d12ff8900b23eee6b2529d6a3cd339a8caa
2021-01-22gdb: move set remote commands to remote.cSimon Marchi3-36/+45
Commands "set debug remote" and "set remotetimeout" are defined in cli/cli-cmds.c, I think it would make more sense for them to be in remote.c. gdb/ChangeLog: * cli/cli-cmds.c (show_remote_debug): Remove. (show_remote_timeout): Remove. (_initialize_cli_cmds): Don't register commands. * remote.c (show_remote_debug): Move here. (show_remote_timeout): Move here. (_initialize_remote): Register commands. Change-Id: Ic4d81888aa4f8dde89d1d29397ef19a08951b80b
2021-01-22gdb: remove TYPE_OBJFILE macroSimon Marchi9-35/+35
Change all users to use the type::objfile method instead. gdb/ChangeLog: * gdbtypes.h (TYPE_OBJFILE): Remove, change all users to use the type::objfile method instead. Change-Id: I6b3f580913fb1fb0cf986b176dba8db68e1fabf9
2021-01-22gdb: remove TYPE_OBJFILE_OWNED macroSimon Marchi6-15/+19
Update all users to use the type::is_objfile_owned method. gdb/ChangeLog: * gdbtypes.h (TYPE_OBJFILE_OWNED): Remove, update all users to use the type::is_objfile_owned method. Change-Id: Icae84d136393ab9f756f50a33ac3cedda13c5ba2
2021-01-22gdb: add owner-related methods to struct typeSimon Marchi6-32/+104
Add the following methods to struct type: * is_objfile_owned * set_owner (objfile and gdbarch overloads) * objfile and arch getters Rename the fields in main_type to ensure no other code accesses them directly. As usual, we can't make them actually private, but giving them the `m_` prefix will help making sure they are not accessed when not supposed to, by convention. Remove the TYPE_OWNER macro to ensure no code uses the type_owner struct directly. gdb/ChangeLog: * gdbtypes.h (TYPE_OBJFILE_OWNED): Adjust. (TYPE_OWNER): Remove. (TYPE_OBJFILE): Adjust. (struct main_type) <flag_objfile_owned>: Rename to... <m_flag_objfile_owned>: ... this. <owner>: Rename to... <m_owner>: ... this. (struct type) <is_objfile_owned, set_owner, objfile, arch>: New methods. (TYPE_ALLOC): Adjust. * gdbtypes.c (alloc_type): Adjust. (alloc_type_arch): Adjust. (alloc_type_copy): Adjust. (get_type_arch): Adjust. (smash_type): Adjust. (lookup_array_range_type): Adjust. (recursive_dump_type): Adjust. (copy_type_recursive): Adjust. * compile/compile-c-types.c (convert_func): Adjust. (convert_type_basic): Adjust. * compile/compile-cplus-types.c (compile_cplus_convert_func): Adjust. * language.c (language_arch_info::type_and_symbol::alloc_type_symbol): Adjust. Change-Id: I7f92e869d9f92e2402a3d3007dd0832e05aa6ac8
2021-01-22gdb/doc: move @menu to the end of the nodeAndrew Burgess2-4/+8
Commit: commit a72d0f3d69896b5fcdc916e0547fe774dcb58614 Date: Tue Jan 12 13:02:30 2021 +0000 gdb/doc: reorder and group sections relating to aliases Added a @menu block into the wrong place within a @node. This commit moves it to the end of the @node, where it should be been placed. gdb/doc/ChangeLog: * gdb.texinfo (Aliases): Move @menu to the end of the node.
2021-01-22gdb/doc: down case contents of @varAndrew Burgess2-2/+6
After a discussion on a recent patch it was pointed out that the contents of a @var should (generally) be lower case. I took a look through the GDB manual and there are a small number of places where the contents are currently upper case, but one in particular seemed like an obvious candidate for being down cased, so lets do that. gdb/doc/ChangeLog: * gdb.texinfo (PowerPC Embedded): Down case contents of @var.
2021-01-22MAINTAINERS: Update my e-mail addressMaciej W. Rozycki3-4/+4
binutils/ * MAINTAINERS: Update my e-mail address. gdb/ * MAINTAINERS: Update my e-mail address. sim/ * MAINTAINERS: Update my e-mail address.
2021-01-22Automatic date update in version.inGDB Administrator1-1/+1
2021-01-21Handle additional connection errorLuis Machado2-0/+8
On Ubuntu 18.04/20.04 I was running into annoying timeouts for gdb.server/server-connect.exp. Those were caused by the ipv6 tests, because they were running into the "Cannot assign requested address" error, originated from the connect syscall. Improve this by handling this additional error in the testsuite library. It still fails for me, but at least it fails pretty quickly and doesn't make the testsuite run take longer. gdb/testsuite/ChangeLog: 2021-01-21 Luis Machado <luis.machado@linaro.org> * lib/gdbserver-support.exp (gdb_target_cmd_ext): Handle a new error message.
2021-01-21Fix build errors for armhfLuis Machado3-4/+11
When building for 32-bit ARM, I ran into a couple build failures. The first one seems to be caused by recent changes to warning switches, leading to the following error: -- In file included from gdb/coffread.c:35:0: gdb/coffread.c: In function "void enter_linenos(file_ptr, int, int, objfile*)": gdb/complaints.h:40:40: error: format "%ld" expects argument of type "long int", but argument 2 has type "file_ptr {aka long long int}" [-Werror=format=] complaint_internal (FMT, ##__VA_ARGS__); \ ^ gdb/coffread.c:1413:7: note: in expansion of macro "complaint" complaint (_("Line number pointer %ld lower than start of line numbers"), ^~~~~~~~~ -- The other one is due to a narrowing conversion in valops.c: -- gdb/valops.c: In function "value* value_assign(value*, value*)": gdb/gdbtypes.h:1798:43: error: narrowing conversion of "type->type::length" from "ULONGEST {aka long long unsigned int}" to "size_t {aka unsigned int}" inside { } [-Werror=narrowing] #define TYPE_LENGTH(thistype) (thistype)->length ~~~~~~~~~~~~^ gdb/valops.c:1252:9: note: in expansion of macro "TYPE_LENGTH" TYPE_LENGTH (type)}); -- Fix both with the following patch. Validated with --enable-targets=all on Ubuntu 18.04/20.04. gdb/ChangeLog: 2021-01-21 Luis Machado <luis.machado@linaro.org> * coffread.c (enter_linenos): Passing string to complaint. * valops.c (value_assign): Make array view.
2021-01-21gdb: convert auto-load to new-style debug macrosSimon Marchi5-102/+92
Function file_is_auto_load_safe was taking a format string and varargs just to output a debug print. This is probably because that function is used in linux-thread-db.c and main.c, but debug_auto_load is static in auto-load.c. I simplified that, making debug_auto_load visible outside of auto-load.c, and making the callers of file_is_auto_load_safe output the debug print themselves. This file uses _() for internationalization of the debug messages. This is not necessary, as these are mostly messages for GDB developers, and it's not used in other files anyway. So I removed them. The rest is pretty much standard. gdb/ChangeLog: * auto-load.h (debug_auto_load): Move here. (auto_load_debug_printf): New. * auto-load.c: Use auto_load_debug_printf. (debug_auto_load): Move to header. * linux-thread-db.c (try_thread_db_load): Use auto_load_debug_printf. * main.c (captured_main_1): Likewise. Change-Id: I468dc2a1d24b7dbf171f55181a11abbfafe70ba1
2021-01-21gdb: remove unused f77_array_offset_tbl from f-valprint.cSimon Marchi2-5/+4
This variable appears to be unused. Its uses were removed in commit 3e2e34f8623d ("fort_dyn_array: Use value constructor instead of raw-buffer manipulation.") back in 2016. gdb/ChangeLog: * f-valprint.c (f77_array_offset_tbl): Remove. Change-Id: I39ff8d1b402e54ca2ade936f65e540f500cce86e
2021-01-21gdb: convert bfd-cache to new-style debug macrosSimon Marchi2-29/+25
gdb/ChangeLog: * gdb_bfd.c (bfd_cache_debug_printf): New, use throughout file. Change-Id: Ie29948d82adfae7edb3cdcbd61f59a66892fcc99
2021-01-21gdb: use interruptible_select when connecting to a remoteSimon Marchi2-1/+6
When GDB is waiting trying to connect to a remote target and it receives a SIGWINCH (terminal gets resized), the blocking system call gets interrupted and we abort. For example, I connect to some port (on which nothing listens): (gdb) tar rem :1234 ... GDB blocks here, resize the terminal ... :1234: Interrupted system call. The backtrace where GDB is blocked while waiting for the connection to establish is: #0 0x00007fe9db805b7b in select () from /usr/lib/libc.so.6 #1 0x000055f2472e9c42 in gdb_select (n=0, readfds=0x0, writefds=0x0, exceptfds=0x0, timeout=0x7ffe8fafe050) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31 #2 0x000055f24759c212 in wait_for_connect (sock=-1, polls=0x7ffe8fafe300) at /home/simark/src/binutils-gdb/gdb/ser-tcp.c:147 #3 0x000055f24759d0e8 in net_open (scb=0x62500015b900, name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/ser-tcp.c:356 #4 0x000055f2475a0395 in serial_open_ops_1 (ops=0x55f24892ca60 <tcp_ops>, open_name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/serial.c:244 #5 0x000055f2475a01d6 in serial_open (name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/serial.c:231 #6 0x000055f2474d5274 in remote_serial_open (name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/remote.c:5019 #7 0x000055f2474d7025 in remote_target::open_1 (name=0x6020000601d8 ":1234", from_tty=1, extended_p=0) at /home/simark/src/binutils-gdb/gdb/remote.c:5571 #8 0x000055f2474d47d5 in remote_target::open (name=0x6020000601d8 ":1234", from_tty=1) at /home/simark/src/binutils-gdb/gdb/remote.c:4898 #9 0x000055f24776379f in open_target (args=0x6020000601d8 ":1234", from_tty=1, command=0x611000042bc0) at /home/simark/src/binutils-gdb/gdb/target.c:242 Fix that by using interruptible_select in wait_for_connect, instead of gdb_select. Resizing the terminal now no longer aborts the connection. It is still possible to interrupt the connection using ctrl-c. gdb/ChangeLog: * ser-tcp.c (wait_for_connect): Use interruptible_select instead of gdb_select. Change-Id: Ie25577bd1e5699e4847b6b53fdfa10b8c0dc5c89
2021-01-21gdb/testsuite: improve logging in lib/tuiterm.expSimon Marchi2-171/+281
Here's a bonus patch that applies on top of the other two. While debugging TUI test cases, it's hard to know what exactly is happening in the little mind of the terminal emulator. Add some logging for all input processing. Right now I'm interested in seeing what happens to the cursor position, so made it so all operations log the "before" and "after" cursor position. It should help see if any operation is not behaving as expected, w.r.t. the cursor position. Here are some examples of the logging found in gdb.log with this patch applied: +++ Inserting string '+|' +++ Inserted char '+', cursor: (0, 79) -> (1, 0) +++ Inserted char '|', cursor: (1, 0) -> (1, 1) +++ Inserted string '+|', cursor: (0, 79) -> (1, 1) +++ Cursor Horizontal Absolute (80), cursor: (1, 1) -> (1, 79) In the last line, note that the argument is 80 and we move to 79, that's because the position in the argument to the control sequence is 1-based, while our indexing is 0-based. gdb/testsuite/ChangeLog: * lib/tuiterm.exp (_log, _log_cur): New, use throughout. Change-Id: Ibf570d4b2867729ce65bea8c193343a8a846170d
2021-01-21gdb/doc: reorder and group sections relating to aliasesAndrew Burgess2-189/+204
This started by observing that the section name: Automatically prepend default arguments to user-defined aliases Is very long. When this is rendered in the PDF manual (at least for me), this name is so long that in the table of contents the page number ends up being misaligned. My first thought was we could drop the 'to user-defined aliases' bit if this section became a sub-section of the section on aliases. So then I looked for a section with 'aliases' in its name, and couldn't find one. It turns out that aliases are documented in a section called: Creating new spellings of existing commands Which (to me) seems an odd aspect of aliases to emphasise. So, in this patch I make the following changes: - Move the section on aliases earlier in the manual, this is now immediately after the section about creating user defined commands. This made more sense to me. - Rename the section on aliases from 'Creating new spellings of existing commands' to 'Command Aliases'. - Update the wording of the first paragraph in the 'Command Aliases' section so that it reads better given the new name. - Add a cross-reference from the 'Command Aliases' section to the 'Python' section now that the aliases section comes first. - Down case all the text inside @var within this section as this is the correct style for the GDB manual. - Move the section on default args to become a sub-section of the 'Command Aliases' section, and rename this sub-section from 'Automatically prepend default arguments to user-defined aliases' to 'Default Arguments'. - Add @menu into the 'Command Aliases' section to link to the 'Default Arguments' subsection. - Add a @cindex entry to the default arguments sub-section. gdb/doc/ChangeLog: * gdb.texinfo (Commands): Update menu. (Extending GDB): Likewise. (Command aliases default args): Moved later into the document, added a cindex entry. Renamed the section 'Automatically prepend default arguments to user-defined aliases' to 'Default Arguments'. (Aliases): Moved earlier in the document. Minor rewording of the first paragraph, down-cased the text inside all uses of @var, and added a cross reference to the Python code. Renamed the section 'Creating new spellings of existing commands' to 'Command Aliases'.
2021-01-21Add Python support for hardware breakpointsHannes Domani6-2/+53
This allows the creation of hardware breakpoints in Python with gdb.Breakpoint(type=gdb.BP_HARDWARE_BREAKPOINT) And they are included in the sequence returned by gdb.breakpoints(). gdb/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * python/py-breakpoint.c (bppy_get_location): Handle bp_hardware_breakpoint. (bppy_init): Likewise. (gdbpy_breakpoint_created): Likewise. gdb/doc/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * python.texi (Breakpoints In Python): Document gdb.BP_HARDWARE_BREAKPOINT. gdb/testsuite/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * gdb.python/py-breakpoint.exp: Add tests for hardware breakpoints.
2021-01-21gdb: convert arm to new-style debug macrosSimon Marchi2-19/+23
gdb/ChangeLog: * arm-tdep.c (arm_debug_printf): Add and use throughout file. Change-Id: Iec5c2955cb79d8c0288ffded2c8a58b7eb7e3554
2021-01-21PR27221, 058430b4a1 warnings while assembling the Linux kernelAlan Modra6-22/+13
PR 27221 * dwarf2dbg.c (dwarf2_gen_line_info_1): Don't warn about ignored line number info when gas is generating it. * testsuite/gas/elf/dwarf2-20.d: Adjust to not expect warnings. * testsuite/gas/m68hc11/indexed12.d: Likewise. * testsuite/gas/elf/elf.exp: Don't run warn-2. * gas/testsuite/gas/elf/warn-2.s: Delete.
2021-01-21PR27218, memory access violation in dwarf2dbg.cAlan Modra2-13/+20
PR 27218 * dwarf2dbg.c (dwarf2_gen_line_info): Correct setting of dwarf_level. (dwarf2_directive_filename, dwarf2_directive_loc): Likewise, and error for negative file numbers.
2021-01-21mips XPASS pr26936Alan Modra2-5/+7
git commit 994b25132814 "Ignore section symbols when matching linkonce with comdat" cured the reason why this test used to fail on mips. * testsuite/ld-elf/pr26936.d: No longer xfail mips.
2021-01-20gdb: change debug_bfd_cache to boolSimon Marchi2-9/+16
gdb/ChangeLog: * gdb_bfd.c (debug_bfd_cache): Change type to bool. (_initialize_gdb_bfd): Adjust. Change-Id: I90fdcc2e2d405653d0eba776f316bcec361b2d18
2021-01-20gdb/testsuite: use multi_line in gdb.base/skip.expSimon Marchi1-30/+30
This will make it easier to modify, in particular add some indentation. It is also a bit nicer to read, in my opinion. gdb/testsuite/ChangeLog; * gdb.base/skip.exp: Use multi_line where relevant. Change-Id: Ia11712aac77344e0b8a836f4181d67e1cad3826c
2021-01-20gdb/dwarf: add assertion in maybe_queue_comp_unitSimon Marchi2-1/+11
The symptom that leads to this is the crash described in PR 26828: /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:23478:25: runtime error: member access within null pointer of type 'struct dwarf2_cu' The line of the crash is the following, in follow_die_offset: if (target_cu != cu) target_cu->ancestor = cu; <--- HERE The line that assign nullptr to `target_cu` is the `per_objfile->get_cu` call after having called maybe_queue_comp_unit: /* If necessary, add it to the queue and load its DIEs. */ if (maybe_queue_comp_unit (cu, per_cu, per_objfile, cu->language)) load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu), false, cu->language); target_cu = per_objfile->get_cu (per_cu); <--- HERE Some background: there is an invariant, documented in maybe_queue_comp_unit's doc, that if a CU is queued for expansion (present in dwarf2_per_bfd::queue), then its DIEs are loaded in memory. "its DIEs are loaded in memory" is a synonym for saying that a dwarf2_cu object exists for this CU. Yet another way to say it is that `per_objfile->get_cu (per_cu)` returns something not nullptr for that CU. The crash documented in PR 26828 triggers some hard-to-reproduce sequence that ends up violating the invariant: - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A - The DIE in CU A requires some DIE in CU B - follow_die_offset calls maybe_queue_comp_unit. maybe_queue_comp_unit sees CU B is not queued and its DIEs are not loaded, so it enqueues it and returns 1 to its caller - meaning "the DIEs are not loaded, you should load them" - prompting follow_die_offset to load the DIEs by calling load_full_comp_unit - Note that CU B is enqueued by maybe_queue_comp_unit even if it has already been expanded. It's a bit useless (and causes trouble, see next patch), but that's how it works right now. - Since we entered the dwarf2/read code through dwarf2_fetch_die_type_sect_off, nothing processes the queue, so we exit the dwarf2/read code with CU B still lingering in the queue. - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again - The DIE in CU A requires some DIE in CU B, again - This time, maybe_queue_comp_unit sees that CU B is in the queue. Because of the invariant that if a CU is in the queue, its DIEs are loaded in the memory, it returns 0 to its caller, meaning "you don't need to load the DIEs!". - That happens to be true, so everything is fine for now. - Time passes, some things call dwarf2_per_objfile::age_comp_units enough so that CU B's age becomes past the dwarf_max_cache_age threshold. age_comp_units proceeds to free CU B's DIEs. Remember that CU B is still lingering in the queue (oops, the invariant just got violated). - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again - The DIE in CU A requires some DIE in CU B, again - maybe_queue_comp_unit sees that CU B is in the queue, so returns to its caller "you don't need to load the DIEs!". However, we know at this point this is false. - follow_die_offset doesn't load the DIEs and tries to obtain the DIEs for CU B: target_cu = per_objfile->get_cu (per_cu); But since they are not loaded, target_cu is nullptr, and we get the crash mentioned above a few lines after that. This patch adds an assertions in maybe_queue_comp_unit to verify the invariant, to make sure it doesn't return a falsehood to its caller. The current patch doesn't fix the issue (the next patch does), but it makes it so we catch the problem earlier and get this assertion failure instead of a segmentation fault: /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9100: internal-error: int maybe_queue_comp_unit(dwarf2_cu*, dwarf2_per_cu_data*, dwarf2_per_objfile*, language): Assertion `per_objfile->get_cu (per_cu) != nullptr' failed. gdb/ChangeLog: PR gdb/26828 * dwarf2/read.c (maybe_queue_comp_unit): Add assertion. Change-Id: I4e51bd7bd58773f9fadf480179cbc4bae61508fe
2021-01-20gdb/dwarf: add some logging in dwarf2/read.cSimon Marchi2-0/+20
This patch adds some logging that helped me diagnose the problems fixed later in this series. I'm thinking that if it helped me now, it could help somebody else (or myself) in the future, so I might as well add them for real. They can happen quite frequently and be noisy, so I used dwarf_read_debug_printf_v for them, which means they'll only print if `set debug dwarf-read` is >= 2. gdb/ChangeLog: * dwarf2/read.c (follow_die_offset): Add logging. (dwarf2_per_objfile::age_comp_units): Add logging. Change-Id: I7483c0b05c37bc9710b9b5d40e272935bc010863
2021-01-20gdb: make some variables staticSimon Marchi43-68/+124
I'm trying to enable clang's -Wmissing-variable-declarations warning. This patch fixes all the obvious spots where we can simply add "static" (at least, found when building on x86-64 Linux). gdb/ChangeLog: * aarch64-linux-tdep.c (aarch64_linux_record_tdep): Make static. * aarch64-tdep.c (tdesc_aarch64_list, aarch64_prologue_unwind, aarch64_stub_unwind, aarch64_normal_base, ): Make static. * arm-linux-tdep.c (arm_prologue_unwind): Make static. * arm-tdep.c (struct frame_unwind): Make static. * auto-load.c (auto_load_safe_path_vec): Make static. * csky-tdep.c (csky_stub_unwind): Make static. * gdbarch.c (gdbarch_data_registry): Make static. * gnu-v2-abi.c (gnu_v2_abi_ops): Make static. * i386-netbsd-tdep.c (i386nbsd_mc_reg_offset): Make static. * i386-tdep.c (i386_frame_setup_skip_insns, i386_tramp_chain_in_reg_insns, i386_tramp_chain_on_stack_insns): Make static. * infrun.c (observer_mode): Make static. * linux-nat.c (sigchld_action): Make static. * linux-thread-db.c (thread_db_list): Make static. * maint-test-options.c (maintenance_test_options_list): * mep-tdep.c (mep_csr_registers): Make static. * mi/mi-cmds.c (struct mi_cmd_stats): Remove struct type name. (stats): Make static. * nat/linux-osdata.c (struct osdata_type): Make static. * ppc-netbsd-tdep.c (ppcnbsd_reg_offsets): Make static. * progspace.c (last_program_space_num): Make static. * python/py-param.c (struct parm_constant): Remove struct type name. (parm_constants): Make static. * python/py-record-btrace.c (btpy_list_methods): Make static. * python/py-record.c (recpy_gap_type): Make static. * record.c (record_goto_cmdlist): Make static. * regcache.c (regcache_descr_handle): Make static. * registry.h (DEFINE_REGISTRY): Make definition static. * symmisc.c (std_in, std_out, std_err): Make static. * top.c (previous_saved_command_line): Make static. * tracepoint.c (trace_user, trace_notes, trace_stop_notes): Make static. * unittests/command-def-selftests.c (nr_duplicates, nr_invalid_prefixcmd, lists): Make static. * unittests/observable-selftests.c (test_notification): Make static. * unittests/optional/assignment/1.cc (counter): Make static. * unittests/optional/assignment/2.cc (counter): Make static. * unittests/optional/assignment/3.cc (counter): Make static. * unittests/optional/assignment/4.cc (counter): Make static. * unittests/optional/assignment/5.cc (counter): Make static. * unittests/optional/assignment/6.cc (counter): Make static. gdbserver/ChangeLog: * ax.cc (bytecode_address_table): Make static. * debug.cc (debug_file): Make static. * linux-low.cc (stopping_threads): Make static. (step_over_bkpt): Make static. * linux-x86-low.cc (amd64_emit_ops, i386_emit_ops): Make static. * tracepoint.cc (stop_tracing_bkpt, flush_trace_buffer_bkpt, alloced_trace_state_variables, trace_buffer_ctrl, tracing_start_time, tracing_stop_time, tracing_user_name, tracing_notes, tracing_stop_note): Make static. Change-Id: Ic1d8034723b7802502bda23770893be2338ab020
2021-01-20gdb/remote.c: address conflicting enum and method nameJoel Sherrill2-5/+15
When building with gcc 4.8, we get: CXX remote.o cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ [enabled by default] /home/smarchi/src/binutils-gdb/gdb/remote.c:1157:38: error: 'resume_state' is not a class, namespace, or enumeration enum resume_state m_resume_state = resume_state::NOT_RESUMED; ^ It looks like gcc 4.8 doesn't like that there is an enum class named resume_state as well as a method. Since it's an easy fix, rename the method to get_remote_state to avoid the clash. gdb/ChangeLog: PR gdb/27219 * remote.c (struct remote_thread_info) <resume_state>: Rename to... <get_resume_state>: ... this. (remote_target::resume): Adjust. (remote_target::commit_resume): Adjust. (remote_target::select_thread_for_ambiguous_stop_reply): Adjust. Change-Id: Ib86c877a4c75ee671d69c27ed06cb8f57bc087db
2021-01-21Automatic date update in version.inGDB Administrator1-1/+1
2021-01-20gdb/testsuite: rename _cur_x/_cur_y to _cur_col/_cur_row in lib/tuiterm.expSimon Marchi2-86/+94
I am having trouble remembering which of _cur_x/_cur_y is columns and which is rows, so renaming them helps. We already have _rows and _cols to represent the terminal size, so I think that makes sense to name the "_cur" variables accordingly. gdb/testsuite/ChangeLog: * lib/tuiterm.exp: Rename _cur_x/_cur_y to _cur_col/_cur_row. Change-Id: I6abd3cdfdb295d8abde12dcd5f0ae09f18f07967
2021-01-20gdb/testsuite: add links for handled control sequences in lib/tuiterm.expSimon Marchi2-9/+49
This code can be a bit cryptic for those who don't know terminal control sequences very well. This patch adds links for all the handled sequences, so it's easy to get some doc to follow the code. I linked to a VT510 manual, because I think it's well formatted and easy to read. There's only the repeat sequence (_csi_b) which I haven't found in it, it looks to be xterm-specific or something. I also tried to use the sequence names as they are in the manual. gdb/testsuite/ChangeLog: * lib/tuiterm.exp: Add links in comments. Change-Id: I670b947a238e5e9bcab7c476a20eb3c31cf2909d
2021-01-20[gdb/testsuite] Fix gdb.python/py-format-string.exp with -m32Tom de Vries2-2/+9
When running test-case gdb.python/py-format-string.exp with target board unix/-m32, we run into: ... (gdb) python print \ (gdb.parse_and_eval ('a_base_ref').format_string (deref_refs=True))^M @0xffffc468: {_vptr.Base = 0x80487e0 <vtable for Deriv+8>, a = 42, \ static a_static_member = 2019}^M (gdb) FAIL: gdb.python/py-format-string.exp: format_string: \ lang_cpp: a_base_ref with option deref_refs: deref_refs=true ... while with -m64, we have instead: ... @0x7fffffffd170: {_vptr.Base = 0x400910 <vtable for Deriv+16>, a = 42, \ static a_static_member = 2019}^M (gdb) PASS: gdb.python/py-format-string.exp: format_string: \ lang_cpp: a_base_ref with option deref_refs: deref_refs=true ... The vtable contains pointer entries which are 4-byte for -m32 and 8-byte for -m64, so it's not surprising the offsets (Deriv+8 vs. Deriv+16) differ. Fix this by allow Deriv+$decimal. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-20 Tom de Vries <tdevries@suse.de> * gdb.python/py-format-string.exp: Allow Deriv+$decimal as vtable offset.
2021-01-20[gdb/testsuite] Skip gdb.rust/*.exp for target board unix/-m32Tom de Vries2-1/+20
When running gdb.rust/*.exp with target board unix/-m32, we see: ... Running src/gdb/testsuite/gdb.rust/union.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/modules.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/unsized.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/simple.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/watch.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/traits.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/expr.exp ... Running src/gdb/testsuite/gdb.rust/rust-style.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/methods.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/generics.exp ... gdb compile failed, error: Unrecognized option: 'm' === gdb Summary === nr of expected passes 95 nr of untested testcases 9 ... Fix this by testing for -m32 in the target board multilib_flags in skip_rust_tests. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-20 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (skip_rust_tests): Skip if multilib_flags contains -m32.
2021-01-20Fix a few stap parser issues and add a new test for probe expressionsSergio Durigan Junior5-5/+155
The creation of this patch was motivated by Tom's "Change handling of '!' operator in stap probes" patch. While reviewing his patch, I stumbled upon a few issues with the stap expression parser. They are: - As it turns out, even with Tom's patch applied the parser doesn't properly handle the '!' operator. The underlying issue was the fact that stap_parse_argument_conditionally also needed to be patched in order to recognize '!' as an operator that is part of a single operand, and parse it accordingly. - While writing the testcase I'm proposing on this patch, I found that parenthesized sub-expressions were not being parsed correctly when there was another term after them. For example: 1 - (2 + 3) + 4 In this case, the parser was considering "1" to be the left-side of the expression, and "(2 + 3) + 4" to be the right-side. The patch fixes the parser by making it identify whether a parenthesized sub-expression has just been parsed, and act accordingly. I've tested this on my Debian testing amd64, and everything seems OK. gdb/ChangeLog: 2021-01-20 Sergio Durigan Junior <sergiodj@sergiodj.net> Tom Tromey <tom@tromey.com> * stap-probe.c (stap_parse_single_operand): Handle '!' operator. (stap_parse_argument_conditionally): Likewise. Skip spaces after processing open-parenthesis sub-expression. (stap_parse_argument_1): Skip spaces after call to stap_parse_argument_conditionally. Handle case when right-side expression is a parenthesized sub-expression. Skip spaces after call to stap_parse_argument_1. gdb/testsuite/ChangeLog: 2021-01-20 Sergio Durigan Junior <sergiodj@sergiodj.net> * gdb.arch/amd64-stap-expressions.S: New file. * gdb.arch/amd64-stap-expressions.exp: New file.
2021-01-20[gdb/server] Don't overwrite fs/gs_base with -m32Tom de Vries2-22/+38
Consider a minimal test-case test.c: ... int main (void) { return 0; } ... compiled with -m32: ... $ gcc test.c -m32 ... When running the exec using gdbserver on openSUSE Factory (currently running a linux kernel version 5.10.5): ... $ gdbserver localhost:12345 a.out ... to which we connect in a gdb session, we run into a segfault in the inferior: ... $ gdb -batch -q -ex "target remote localhost:12345" -ex continue Program received signal SIGSEGV, Segmentation fault. 0xf7dd8bd2 in init_cacheinfo () at ../sysdeps/x86/cacheinfo.c:761 ... The segfault is caused by gdbserver overwriting $gs_base with 0 using PTRACE_SETREGS. After it is overwritten, the next use of $gs in the inferior will trigger the segfault. Before linux kernel version 5.9, the value used by PTRACE_SETREGS for $gs_base was ignored, but starting version 5.9, the linux kernel has support for intel architecture extension FSGSBASE, which allows users to modify $gs_base, and consequently PTRACE_SETREGS can no longer ignore the $gs_base value. The overwrite of $gs_base with 0 is done by a memset in x86_fill_gregset, which was added in commit 9e0aa64f551 "Fix gdbserver qGetTLSAddr for x86_64 -m32". The memset intends to zero-extend 32-bit registers that are tracked in the regcache to 64-bit when writing them into the PTRACE_SETREGS data argument. But in addition, it overwrites other registers that are not tracked in the regcache, such as $gs_base. Fix the segfault by redoing the fix from commit 9e0aa64f551 in minimal form. Tested on x86_64-linux: - openSUSE Leap 15.2 (using kernel version 5.3.18): - native - gdbserver -m32 - -m32 - openSUSE Factory (using kernel version 5.10.5): - native - m32 gdbserver/ChangeLog: 2021-01-20 Tom de Vries <tdevries@suse.de> * linux-x86-low.cc (collect_register_i386): New function. (x86_fill_gregset): Remove memset. Use collect_register_i386.
2021-01-20PowerPC: Don't generate unused section symbolsAlan Modra25-191/+87
PowerPC version of git commit d1bcae833b. bfd/ * elf32-ppc.c: Delete outdated comment. (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Define. * elf64-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Define. gas/ * testsuite/gas/ppc/power4.d: Adjust for removal of section sym. * testsuite/gas/ppc/test1elf32.d: Likewise. * testsuite/gas/ppc/test1elf64.d: Likewise. ld/ * testsuite/ld-powerpc/relbrlt.s: Make symbols global. * testsuite/ld-powerpc/relbrlt.d: Adjust to suit. * testsuite/ld-powerpc/tlsget.d: Adjust for reordered stubs. * testsuite/ld-powerpc/tlsget.wf: Likewise. * testsuite/ld-powerpc/tlsget2.d: Likewise. * testsuite/ld-powerpc/tlsget2.wf: Likewise. * testsuite/ld-powerpc/tlsexe.r: Adjust for removed section syms. * testsuite/ld-powerpc/tlsexe32.r: Likewise. * testsuite/ld-powerpc/tlsexe32no.r: Likewise. * testsuite/ld-powerpc/tlsexeno.r: Likewise. * testsuite/ld-powerpc/tlsexenors.r: Likewise. * testsuite/ld-powerpc/tlsexers.r: Likewise. * testsuite/ld-powerpc/tlsexetoc.r: Likewise. * testsuite/ld-powerpc/tlsexetocrs.r: Likewise. * testsuite/ld-powerpc/tlsso.r: Likewise. * testsuite/ld-powerpc/tlsso32.r: Likewise. * testsuite/ld-powerpc/tlstocso.r: Likewise.
2021-01-20PowerPC64 synthetic symbolsAlan Modra2-1/+7
If an assembler trims off unused section symbols there may be no section symbols. This means that testing for the .opd section symbol needs to test both the section name and symbol flags. * elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Don't assume section symbols are present.
2021-01-20Automatic date update in version.inGDB Administrator1-1/+1
2021-01-19use DISABLE_COPY_AND_ASSIGN in switch_thru_all_uisLancelot SIX2-5/+6
In switch_thru_all_uis, a pre-c++11 way of removing copy constructor and assignment operator is used. This patch uses the DISABLE_COPY_AND_ASSIGN macro which does the right thing for pre and post c++11. gdb/Changelog: 2021-01-19 Lancelot SIX <lsix@lancelotsix.com> * top.h (switch_thru_all_uis): Use DISABLE_COPY_AND_ASSIGN.
2021-01-19trad-frame cleanupsLuis Machado28-232/+183
With the new member functions for struct trad_frame_saved_reg, there is no need to invoke some of the set/get functions anymore. This patch removes those and adjusts all callers. Even though the most natural initial state of a saved register value is UNKNOWN, there are target backends relying on the previous initial state of REALREG set to a register's own number. I noticed this in at least a couple targets: aarch64 and riscv. Because of that, I decided to keep the reset function that sets the set of register values to REALREG. I can't exercise all the targets to make sure the initial state change won't break things, hence why it is risky to change the default. Validated with --enable-targets=all on aarch64-linux Ubuntu 18.04/20.04. gdb/ChangeLog 2021-01-19 Luis Machado <luis.machado@linaro.org> * trad-frame.h (trad_frame_saved_reg) <set_value_bytes>: Allocate memory and save data. (trad_frame_set_value, trad_frame_set_realreg, trad_frame_set_addr) (trad_frame_set_unknown, trad_frame_set_value_bytes) (trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p) (trad_frame_value_bytes_p): Remove. (trad_frame_reset_saved_regs): Adjust documentation. * trad-frame.c (trad_frame_alloc_saved_regs): Initialize via a constructor and reset the state of the registers. (trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p) (trad_frame_value_bytes_p, trad_frame_set_value) (trad_frame_set_realreg, trad_frame_set_addr) (trad_frame_set_unknown, trad_frame_set_value_bytes): Remove. (trad_frame_set_reg_realreg): Update to call member function. (trad_frame_set_reg_addr, trad_frame_set_reg_value_bytes): Likewise. (trad_frame_get_prev_register): Likewise. * aarch64-tdep.c (aarch64_analyze_prologue) (aarch64_analyze_prologue_test, aarch64_make_prologue_cache_1) (aarch64_prologue_prev_register): Update to use member functions. * alpha-mdebug-tdep.c (alpha_mdebug_frame_unwind_cache): Likewise. * alpha-tdep.c (alpha_heuristic_frame_unwind_cache): Likewise. * arc-tdep.c (arc_print_frame_cache, arc_make_frame_cache): Likewise. * arm-tdep.c (arm_make_prologue_cache, arm_exidx_fill_cache) (arm_make_epilogue_frame_cache): Likewise. * avr-tdep.c (avr_frame_unwind_cache) (avr_frame_prev_register): Likewise. * cris-tdep.c (cris_scan_prologue): Likewise. * csky-tdep.c (csky_frame_unwind_cache): Likewise. * frv-tdep.c (frv_analyze_prologue): Likewise. * hppa-tdep.c (hppa_frame_cache, hppa_fallback_frame_cache): Likewise. * lm32-tdep.c (lm32_frame_cache): Likewise. * m32r-tdep.c (m32r_frame_unwind_cache): Likewise. * m68hc11-tdep.c (m68hc11_frame_unwind_cache): Likewise. * mips-tdep.c (set_reg_offset, mips_insn16_frame_cache) (mips_micro_frame_cache, mips_insn32_frame_cache): Likewise. (reset_saved_regs): Adjust to set realreg. * riscv-tdep.c (riscv_scan_prologue, riscv_frame_cache): Adjust to call member functions. * rs6000-tdep.c (rs6000_frame_cache, rs6000_epilogue_frame_cache) * s390-tdep.c (s390_prologue_frame_unwind_cache) (s390_backchain_frame_unwind_cache): Likewise. * score-tdep.c (score7_analyze_prologue) (score3_analyze_prologue, score_make_prologue_cache): Likewise. * sparc-netbsd-tdep.c (sparc32nbsd_sigcontext_saved_regs): Likewise. * sparc-sol2-tdep.c (sparc32_sol2_sigtramp_frame_cache): Likewise. * sparc64-netbsd-tdep.c (sparc64nbsd_sigcontext_saved_regs): Likewise. * sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_cache): Likewise. * tilegx-tdep.c (tilegx_analyze_prologue) (tilegx_frame_cache): Likewise. * v850-tdep.c (v850_frame_cache): Likewise. * vax-tdep.c (vax_frame_cache): Likewise.
2021-01-19Convert some frame functions to use gdb::array_view.Luis Machado27-84/+147
This patch converts the most obvious functions from gdb/frame.h to use the gdb::array_view abstraction. I've converted the ones that used buffer + length. There are others using only the buffer, with an implicit size. I did not touch those for now. But it would be nice to pass the size for safety. Tested with --enable-targets=all on Ubuntu 18.04/20.04 aarch64-linux. gdb/ChangeLog 2021-01-19 Luis Machado <luis.machado@linaro.org> * frame.h (get_frame_register_bytes): Pass a gdb::array_view instead of buffer + length. (put_frame_register_bytes): Likewise. Adjust documentation. (get_frame_memory): Pass a gdb::array_view instead of buffer + length. (safe_frame_unwind_memory): Likewise. * frame.c (get_frame_register_bytes, put_frame_register_bytes) (get_frame_memory, safe_frame_unwind_memory): Adjust to use gdb::array_view. * amd64-fbsd-tdep.c (amd64fbsd_sigtramp_p): Likewise. * amd64-linux-tdep.c (amd64_linux_sigtramp_start): Likewise. * amd64-obsd-tdep.c (amd64obsd_sigtramp_p): Likewise. * arc-linux-tdep.c (arc_linux_is_sigtramp): Likewise. * cris-tdep.c (cris_sigtramp_start, cris_rt_sigtramp_start): Likewise. * dwarf2/loc.c (rw_pieced_value): Likewise. * hppa-tdep.c (hppa_frame_cache): Likewise. * i386-fbsd-tdep.c (i386fbsd_sigtramp_p): Likewise. * i386-gnu-tdep.c (i386_gnu_sigtramp_start): Likewise. * i386-linux-tdep.c (i386_linux_sigtramp_start) (i386_linux_rt_sigtramp_start): Likewise. * i386-obsd-tdep.c (i386obsd_sigtramp_p): Likewise. * i386-tdep.c (i386_register_to_value): Likewise. * i387-tdep.c (i387_register_to_value): Likewise. * ia64-tdep.c (ia64_register_to_value): Likewise. * m32r-linux-tdep.c (m32r_linux_sigtramp_start) (m32r_linux_rt_sigtramp_start): Likewise. * m68k-linux-tdep.c (m68k_linux_pc_in_sigtramp): Likewise. * m68k-tdep.c (m68k_register_to_value): Likewise. * mips-tdep.c (mips_register_to_value) (mips_value_to_register): Likewise. * ppc-fbsd-tdep.c (ppcfbsd_sigtramp_frame_sniffer) (ppcfbsd_sigtramp_frame_cache): Likewise. * ppc-obsd-tdep.c (ppcobsd_sigtramp_frame_sniffer) (ppcobsd_sigtramp_frame_cache): Likewise. * rs6000-tdep.c (rs6000_in_function_epilogue_frame_p) (rs6000_register_to_value): Likewise. * tilegx-tdep.c (tilegx_analyze_prologue): Likewise. * tramp-frame.c (tramp_frame_start): Likewise. * valops.c (value_assign): Likewise.
2021-01-19sim: ppc: update version script usageMike Frysinger2-2/+7
This matches the changes in the common code.
2021-01-19Use gdb::array_view for setting value bytes in trad-frameLuis Machado4-19/+28
This patch updates the functions setting value bytes in trad-frame to use a gdb::array_view instead of passing a buffer and a size. gdb/ChangeLog: 2021-01-19 Luis Machado <luis.machado@linaro.org> * aarch64-linux-tdep.c (aarch64_linux_restore_vreg): Pass in an array_view. * trad-frame.c (trad_frame_set_value_bytes): Use gdb::array_view instead of buffer and size. (trad_frame_set_reg_value_bytes): Likewise. * trad-frame.h (trad_frame_set_reg_value_bytes): Likewise. (trad_frame_set_value_bytes): Likewise.
2021-01-19libctf, create: fix ctf_type_add of structs with unnamed membersNick Alcock5-0/+106
Our recent commit to support unnamed structure members better ditched the old ctf_member_iter iterator body in favour of ctf_member_next. However, these functions treat unnamed structure members differently: ctf_member_iter just returned whatever the internal representation contained, while ctf_member_next took care to always return "" rather than sometimes returning "" and sometimes NULL depending on whether the dict was dynamic (a product of ctf_create) or not (a product of ctf_open). After this commit, ctf_member_iter did the same. It was always a bug for external callers not to treat a "" return from these functions as if it were NULL, so only buggy callers could be affected -- but one of those buggy callers was ctf_add_type, which assumed that it could just take whatever name was returned from ctf_member_iter and slam it directly into the internal representation of a dynamic dict -- which expects NULL for unnamed members, not "". The net effect of all of this is that taking a struct containing unnamed members and ctf_add_type'ing it into a dynamic dict produced a dict whose unnamed members were inaccessible to ctf_member_info (though if you wrote that dict out and then ctf_open'ed it, they would magically reappear again). Compensate for this by suitably transforming a "" name into NULL in the internal representation, as should have been done all along. libctf/ChangeLog 2021-01-19 Nick Alcock <nick.alcock@oracle.com> * ctf-create.c (membadd): Transform ""-named members into NULL-named ones. * testsuite/libctf-regression/type-add-unnamed-struct*: New test.
generated by cgit v1.1 at 2024-08-05 01:44:33 +0000