aboutsummaryrefslogtreecommitdiff
path: root/gdb/procfs.c
AgeCommit message (Collapse)AuthorFilesLines
2024-06-07gdb: remove get_exec_fileSimon Marchi1-0/+3
I believe that the get_exec_file function is unnecessary, and the code can be simplified if we remove it. Consider for instance when you "run" a program on Linux with native debugging. 1. run_command_1 obtains the executable file from `current_program_space->exec_filename ()` 2. it passes it to `run_target->create_inferior()`, which is `inf_ptrace_target::create_inferior()` in this case, which then passes it to `fork_inferior()` 3. `fork_inferior()` then has a fallback, where if the passed exec file is nullptr, it gets its from `get_exec_file()`. 4. `get_exec_file()` returns `current_program_space->exec_filename ()` - just like the things we started with - or errors out if the current program space doesn't have a specified executable. If there's no exec filename passed in step 1, there's not going to be any in step 4, so it seems pointless to call `get_exec_file()`, we could just error out when `exec_file` is nullptr. But we can't error out directly in `fork_inferior()`, since the error is GDB-specific, and that function is shared with GDBserver. Speaking of GDBserver, all code paths that lead to `fork_inferior()` provide a non-nullptr exec file. Therefore, to simplify things: - Make `fork_inferior()` assume that the passed exec file is not nullptr, don't call `get_exec_file()` - Change some targets (darwin-nat, go32-nat, gnu-nat, inf-ptrace, nto-procfs, procfs) to error out when the exec file passed to their create_inferior method is nullptr. Some targets are fine with a nullptr exec file, so we can't check that in `run_command_1()`. - Add the `no_executable_specified_error()` function, which re-uses the error message that `get_exec_file()` had. - Change some targets (go32-nat, nto-procfs) to not call `get_exec_file()`, since it's pointless for the same reason as in the example above, if it returns, it's going the be the same value as the `exec_file` parameter. Just rely on `exec_file`. - Remove the final use of `get_exec_file()`, in `load_command()`. - Remove the `get_exec_file()` implementations in GDB and GDBserver and remove the shared declaration. Change-Id: I601c16498e455f7baa1f111a179da2f6c913baa3 Approved-By: Tom Tromey <tom@tromey.com>
2024-06-07gdb: replace `get_exec_file (0)` calls with ↵Simon Marchi1-3/+4
`current_program_space->exec_filename ()` Calls of `get_exec_file (0)` are equivalent to just getting the exec filename from the current program space. I'm looking to remove `get_exec_file`, so replace these uses with `current_program_space->exec_filename ()`. Remove the `err` parameter of `get_exec_wrapper` since all the calls that remain pass 1, meaning to error out if no executable is specified. Change-Id: I7729ea4c7f03dbb046211cc5aa3858ab3a551965 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-25gdb: remove gdbcmd.hSimon Marchi1-1/+1
Most files including gdbcmd.h currently rely on it to access things actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make things easy, replace all includes of gdbcmd.h with includes of cli/cli-cmds.h. This might lead to some unused includes of cli/cli-cmds.h, but it's harmless, and much faster than going through the 170 or so files by hand. Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f Approved-By: Tom Tromey <tom@tromey.com>
2024-04-22gdb: move store/extract integer functions to extract-store-integer.{c,h}Simon Marchi1-0/+1
Move the declarations out of defs.h, and the implementations out of findvar.c. I opted for a new file, because this functionality of converting integers to bytes and vice-versa seems a bit to generic to live in findvar.c. Change-Id: I524858fca33901ee2150c582bac16042148d2251 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2024-01-04gdb: don't try to style content in error callsAndrew Burgess1-4/+2
While working on a later commit in this series I realised that the error() function doesn't support output styling. Due to the way that output from error() calls is passed around within the exception object and often combined with other output, it's not immediately obvious to me if we should be trying to support styling in this context or not. On inspection, I found one place in GDB where we apparently try to apply styling within the error() output (in procfs.c). I suspect this error() call might not be tested. Rather than try to implement styling in the error() output, right now I'm proposing to just remove the attempt to style error() output. This doesn't mean that someone shouldn't add error() styling in the future, but right now, I'm not planning to do that, I just wanted to fix this in passing. Approved-By: John Baldwin <jhb@FreeBSD.org>
2023-11-30Fix procfs.c compilationRainer Orth1-1/+1
procfs.c doesn't currently compile on Solaris: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual int procfs_target::can_use_hw_breakpoint(bptype, int, int)’: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3017:9: error: ‘ptr_type’ was not declared in this scope; did you mean ‘var_types’? 3017 | type *ptr_type | ^~~~~~~~ | var_types This was caused by this patch: commit 99d9c3b92ca96a7425cbb6b1bf453ede9477a2ee Author: Simon Marchi <simon.marchi@efficios.com> Date: Fri Sep 29 14:24:38 2023 -0400 gdb: remove target_gdbarch Partially undoing it restores the build. Tested on amd64-pc-solaris2.11.
2023-11-21gdb: Replace gdb::optional with std::optionalLancelot Six1-1/+1
Since GDB now requires C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optional -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool.* which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-17gdb: remove get_current_regcacheSimon Marchi1-1/+1
Remove get_current_regcache, inlining the call to get_thread_regcache in callers. When possible, pass the right thread_info object known from the local context. Otherwise, fall back to passing `inferior_thread ()`. This makes the reference to global context bubble up one level, a small step towards the long term goal of reducing the number of references to global context (or rather, moving those references as close as possible to the top of the call tree). No behavior change expected. Change-Id: Ifa6980c88825d803ea586546b6b4c633c33be8d6
2023-10-10gdb: remove target_gdbarchSimon Marchi1-11/+13
This function is just a wrapper around the current inferior's gdbarch. I find that having that wrapper just obscures where the arch is coming from, and that it's often used as "I don't know which arch to use so I'll use this magical target_gdbarch function that gets me an arch" when the arch should in fact come from something in the context (a thread, objfile, symbol, etc). I think that removing it and inlining `current_inferior ()->arch ()` everywhere will make it a bit clearer where that arch comes from and will trigger people into reflecting whether this is the right place to get the arch or not. Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-05gdb: remove print_sys_errmsgAndrew Burgess1-7/+10
This started with me running into this comment in symfile.c: /* FIXME, should use print_sys_errmsg but it's not filtered. */ gdb_printf (_("`%ps' has disappeared; keeping its symbols.\n"), styled_string (file_name_style.style (), filename)); In this particular case I think I disagree with the comment; I think the output should be a warning rather than just a message printed to gdb_stdout, I think when the executable, or some other objfile that is currently being debugged, disappears from disk, this is likely an unexpected situation, and worth warning the user about. So, in theory, I could just call print_sys_errmsg and remove the comment, but that would mean loosing the filename styling in the output... so in the end I remove the comment and updated the code to call warning. But that got me looking at print_sys_errmsg and how it's used. Currently the function takes a string and an errno, and prints, to stderr, the string followed by the result of calling strerror on the errno. In some places the string passed to print_sys_errmsg is just a filename, and this is used when something goes wrong. In these cases, I think calling warning rather than gdb_printf to gdb_stderr, would be better, and in fact, in a couple of places we manually print a "warning" prefix, and then call print_sys_errmsg. And so, for these users I have added a new function warning_filename_and_errno, which takes a filename, which is printed with styling, and an errno, which is passed through strerror and the resulting string printed. This new function calls warning to print its output. I then updated some of the print_sys_errmsg users to use this new function. Some other users of print_sys_errmsg are also emitting what is clearly a warning, however, the string being passed in is more than just a filename, so the new warning_filename_and_errno function can't be used, it would style the whole string. For these users I have switched to calling warning directly, this allows me to style the warning message correctly. Finally, in inflow.c there is one last call to print_sys_errmsg, in this case I just inlined the definition of print_sys_errmsg. This is a really weird case, as after printing this message GDB just does a hard exit. This is pretty old code, dating back to the initial GDB import, I guess it should be updated to call error() maybe, but I'm reluctant to make this change as part of this commit, just in case there's some reason why we can't throw an error at this point. With that done there are now no users of print_sys_errmsg, and so the old function can be removed. While I was doing all of the above I added some additional filename styling in soure.c, this is in an else block where the if contained the print_sys_errmsg call, so these felt related. And finally, while I was updating the uses of print_sys_errmsg in procfs.c, I noticed that we used a static errmsg buffer to format some error strings. As the above changes got rid of one of the users of errmsg I also removed the other two users, and the static buffer. There were a couple of tests that depended on the existing output message format that needed updating. In one case we gained an extra 'warning: ' prefix, and in the other 'Warning: ' becomes 'warning: ', I think in both cases the new output is an improvement. Approved-By: Tom Tromey <tom@tromey.com>
2023-10-05gdb: remove use of a static buffer for building error stringsAndrew Burgess1-13/+14
I noticed in procfs.c that we use a static buffer for building error strings when we could easily use std::string and string_printf to achieve the same result, this commit does that. I ran into this while performing a further refactor/cleanup that will be presented in a later patch in this series, and thought this was worth splitting out into its own patch. As far as I can tell, only Solaris uses procfs.c, so I did a test build on a Solaris machine, and I don't believe that I've broken anything. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-20Remove explanatory comments from includesTom Tromey1-5/+5
I noticed a comment by an include and remembered that I think these don't really provide much value -- sometimes they are just editorial, and sometimes they are obsolete. I think it's better to just remove them. Tested by rebuilding. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-08-23gdb: centralize "[Thread ...exited]" notificationsPedro Alves1-6/+0
Currently, each target backend is responsible for printing "[Thread ...exited]" before deleting a thread. This leads to unnecessary differences between targets, like e.g. with the remote target, we never print such messages, even though we do print "[New Thread ...]". E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we currently see: (gdb) c Continuing. ^C[New Thread 3850398.3887449] [New Thread 3850398.3887500] [New Thread 3850398.3887551] [New Thread 3850398.3887602] [New Thread 3850398.3887653] ... Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c (gdb) Above, we only see "New Thread" notifications, even though threads were deleted. After this patch, we'll see: (gdb) c Continuing. ^C[Thread 3558643.3577053 exited] [Thread 3558643.3577104 exited] [Thread 3558643.3577155 exited] [Thread 3558643.3579603 exited] ... [New Thread 3558643.3597415] [New Thread 3558643.3600015] [New Thread 3558643.3599965] ... Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c (gdb) q This commit fixes this by moving the thread exit printing to common code instead, triggered from within delete_thread (or rather, set_thread_exited). There's one wrinkle, though. While most targest want to print: [Thread ... exited] the Windows target wants to print: [Thread ... exited with code <exit_code>] ... and sometimes wants to suppress the notification for the main thread. To address that, this commits adds a delete_thread_with_code function, only used by that target (so far). This fix was originally posted as part of a larger series: https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/ But didn't really need to be part of that series. In order to get this fix merged sooner, I (Andrew Burgess) have rebased this commit outside of the original series. Any bugs introduced while splitting this patch out and rebasing, are entirely my own. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129 Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
2023-07-06Fix Solaris regression (PR tdep/30252)Pedro Alves1-21/+25
PR tdep/30252 reports that using GDB on Solaris fails an assertion in target_resume: target.c:2648: internal-error: target_resume: Assertion `inferior_ptid != null_ptid' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) The backtrace, after running it through c++filt, looks like: ----- Backtrace ----- 0xa18914 gdb_internal_backtrace_1 /root/binutils-gdb/gdb/bt-utils.c:122 0xa18914 gdb_internal_backtrace() /root/binutils-gdb/gdb/bt-utils.c:168 0xdec834 internal_vproblem /root/binutils-gdb/gdb/utils.c:401 0xdecad8 internal_verror(char const*, int, char const*, __va_list_tag*) /root/binutils-gdb/gdb/utils.c:481 0xf3638c internal_error_loc(char const*, int, char const*, ...) /root/binutils-gdb/gdbsupport/errors.cc:58 0xd70580 target_resume(ptid_t, int, gdb_signal) /root/binutils-gdb/gdb/target.c:2648 0xc59e85 procfs_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>) /root/binutils-gdb/gdb/procfs.c:2187 0xcf6da7 sol_thread_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>) /root/binutils-gdb/gdb/sol-thread.c:442 0xd73711 target_wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>) /root/binutils-gdb/gdb/target.c:2586 ... The problem is that the procfs backend, while inside target_wait, called target_resume without switching to the leader thread of that resumption. The target_resume interface is: /* Resume execution (or prepare for execution) of the current thread (INFERIOR_PTID), while optionally letting other threads of the current process or all processes run free. ... Thus calling target_resume with inferior_ptid == null_ptid is bogus. target_wait (which leads to procfs_target::wait on Solaris) is called with inferior_ptid == null_ptid on entry exactly to help catch such bogus uses. From the backtrace, it seems that the relevant line in question is procfs.c:2187: 2186 /* How to keep going without returning to wfi: */ 2187 target_continue_no_signal (ptid); 2188 goto wait_again; target_continue_no_signal is a small wrapper around target_resume, which would make sense. The fix is to not call target_resume or go via the target stack at all. Instead, factor out a new proc_resume function out of procfs_target::resume, and call that. The new function does not rely on inferior_ptid. I've not been able to test it myself, but Petr confirmed it fixes the assertion failure with his test case, and Marcel Telka also confirmed it solves the problem. Tested-By: Petr Šumbera <petr.sumbera@oracle.com> Tested-By: Marcel Telka <marcel@telka.sk> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30252 Change-Id: I6213c59b081d400a22e799ee621c2eff6dcafbf3
2023-04-04gdb: make find_thread_ptid a process_stratum_target methodSimon Marchi1-3/+3
Make find_thread_ptid (the overload that takes a process_stratum_target) a method of process_stratum_target. Change-Id: Ib190a925a83c6b93e9c585dc7c6ab65efbdd8629 Reviewed-By: Tom Tromey <tom@tromey.com>
2023-02-27Tweak "Using the running image of ..." outputPedro Alves1-1/+1
Currently, "info files" and "info program" on a few native targets show: (gdb) info files Symbols from "/home/pedro/gdb/tests/threads". Native process: Using the running image of child Thread 0x7ffff7d89740 (LWP 1097968). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... (gdb) info program Using the running image of child Thread 0x7ffff7d89740 (LWP 1097968). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Program stopped at 0x555555555278. ... This patch changes them to: (gdb) info files Symbols from "/home/pedro/gdb/tests/threads". Native process: Using the running image of child process 1097968. ^^^^^^^^^^^^^^^ ... (gdb) info program Using the running image of child process 1097968. ^^^^^^^^^^^^^^^ Program stopped at 0x555555555278. ... ... which I think makes a lot more sense in this context. The "info program" manual entry even says: "Display information about the status of your program: whether it is running or not, what process it is, and why it stopped." ^^^^^^^^^^^^^ This change affects ptrace targets, procfs targets, and Windows. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I6aab061ff494a84ba3398cf98fd49efd7a6ec1ca
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-11-27Use false/true for some inferior class members instead of 0/1Philippe Waroquiers1-1/+1
Some class members were changed to bool, but there was still some assignments or comparisons using 0/1. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-17Fix various procfs.c compilation errorsRainer Orth1-15/+9
procfs.c has accumulated several compilation errors lately (some of them new with GCC 12), which are fixed by this patch: * auxv_parse gets: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:144:7: error: ‘int procfs_target::auxv_parse(gdb_byte**, gdb_byte*, CORE_ADDR*, CORE_ADDR*)’ marked ‘override’, but does not override 144 | int auxv_parse (gdb_byte **readptr, | ^~~~~~~~~~ Obviouly, procfs.c was missed in the auxv_parse constification. * dead_procinfo has: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function ‘void dead_procinfo(procinfo*, const char*, int)’: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:563:11: warning: the address of ‘procinfo::pathname’ will never be NULL [-Waddress] 563 | if (pi->pathname) | ~~~~^~~~~~~~ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:238:8: note: ‘procinfo::pathname’ declared here 238 | char pathname[MAX_PROC_NAME_SIZE]; /* Pathname to /proc entry */ | ^~~~~~~~ The warning is correct, so the code can lose support for the NULL pathname case. * create_inferior has this ugly warning: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual void procfs_target::create_inferior(const char*, const std::string&, char**, int)’: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2815:19: warning: ‘char* std::strncpy(char*, const char*, size_t)’ output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] 2815 | strncpy (tryname, p, len); | ~~~~~~~~^~~~~~~~~~~~~~~~~ /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2814:26: note: length computed here 2814 | len = strlen (p); | ~~~~~~~^~~ It seems that this is another case of GCC PR middle-end/88059, which Martin Sebor refuses to fix. So I'm using the hack suggested in the PR to use memcpy instead of strncpy. * find_memory_regions_callback fails with /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In function ‘int find_memory_regions_callback(prmap*, find_memory_region_ftype, void*)’: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3167:18: error: too few arguments to function 3167 | return (*func) ((CORE_ADDR) map->pr_vaddr, | ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ 3168 | map->pr_size, | ~~~~~~~~~~~~~ 3169 | (map->pr_mflags & MA_READ) != 0, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3170 | (map->pr_mflags & MA_WRITE) != 0, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3171 | (map->pr_mflags & MA_EXEC) != 0, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3172 | 1, /* MODIFIED is unknown, pass it as true. */ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3173 | data); | ~~~~~ Again, procfs.c was overlooked when adding the new memory_tagged arg. Unfortunately, it wasn't even documented in gdb/defs.h when it was added in commit 68cffbbd4406b4efe1aa6e18460b1d7ca02549f1 Author: Luis Machado <luis.machado@arm.com> Date: Thu Mar 31 11:42:35 2022 +0100 [AArch64] MTE corefile support With those changes, procfs.c compiles again. Together with the hack from the Solaris gdbsupport breakage reported in PR build/29791, I was able to build and test gdb on both amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi1-2/+2
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-06-08gdb: remove trailing '.' from perror_with_name callsAndrew Burgess1-1/+1
I ran into this error while working on AArch64 GDB: Unable to fetch VFP registers.: Invalid argument. Notice the '.:' in the middle of this error message. This is because of this call in aarch64-linux-nat.c: perror_with_name (_("Unable to fetch VFP registers.")); The perror_with_name function take a string, and adds ': <message>' to the end the string, so I don't think the string that we pass to perror_with_name should end in '.'. This commit removes all of the trailing '.' characters from perror_with_name calls, which give more readable error messages. I don't believe that any of these errors are tested in the testsuite (after a little grepping).
2022-05-13Constify target_pid_to_exec_fileTom Tromey1-2/+2
This changes target_pid_to_exec_file and target_ops::pid_to_exec_file to return a "const char *". I couldn't build many of these targets, but did examine the code by hand -- also, as this only affects the return type, it's normally pretty safe. This brings gdb and gdbserver a bit closer, and allows for the removal of a const_cast as well.
2022-03-31Fix procfs.c compilationRainer Orth1-0/+1
procfs.c doesn't compile on Solaris: /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c: In member function ‘virtual bool procfs_target::info_proc(const char*, info_proc_what)’: /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3302:3: error: ‘gdb_argv’ was not declared in this scope 3302 | gdb_argv built_argv (args); | ^~~~~~~~ /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3303:20: error: ‘built_argv’ was not declared in this scope; did you mean ‘buildargv’? 3303 | for (char *arg : built_argv) | ^~~~~~~~~~ | buildargv Fixed by including "gdbsupport/buildargv.h". Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11.
2022-03-29Unify gdb printf functionsTom Tromey1-55/+55
Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script.
2022-03-29Remove some uses of printf_unfilteredTom Tromey1-4/+4
A number of spots call printf_unfiltered only because they are in code that should not be interrupted by the pager. However, I believe these cases are all handled by infrun's blanket ban on paging, and so can be converted to the default (_filtered) API. After this patch, I think all the remaining _unfiltered calls are ones that really ought to be. A few -- namely in complete_command -- could be replaced by a scoped assignment to pagination_enabled, but for the remainder, the code seems simple enough like this.
2022-01-06Use target_announce_detach in more targetsTom Tromey1-13/+1
target_announce_detach was added in commit 0f48b757 ("Factor out "Detaching from program" message printing"). There, Pedro wrote: (For now, I left the couple targets that print this a bit differently alone. Maybe this could be further pulled out into infcmd.c. If we did that, and those targets want to continue printing differently, this new function could be converted to a target method.) It seems to me that the differences aren't very big, and in some cases other targets handled the output a bit more nicely. In particular, some targets will print a different message when exec_file==NULL, rather than printing the same output with an empty string as exec_file. This patch incorporates the nicer output into target_announce_detach, then changes the remaining ports to use this function.
2022-01-06Introduce target_announce_attachTom Tromey1-13/+1
This introduces target_announce_attach, by analog with target_announce_detach. Then it converts existing targets to use this, rather than emitting their own output by hand.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-12-03gdb: change store_waitstatus to return a target_waitstatus by valueSimon Marchi1-1/+1
store_waitstatus is basically a translation function between a status integer and an equivalent target_waitstatus object. It would make sense for it to take the integer as a parameter and return the target_waitstatus by value. Do that, and rename to host_status_to_waitstatus. Users can then do: ws = host_status_to_waitstatus (status) which does the right thing, given the move constructor of target_waitstatus. Change-Id: I7a07d59d3dc19d3ed66929642f82f44f3e85d61b
2021-10-21gdb, gdbserver: make target_waitstatus safeSimon Marchi1-5/+4
I stumbled on a bug caused by the fact that a code path read target_waitstatus::value::sig (expecting it to contain a gdb_signal value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED. This meant that the active union field was in fact target_waitstatus::value::related_pid, and contained a ptid. The read signal value was therefore garbage, and that caused GDB to crash soon after. Or, since that GDB was built with ubsan, this nice error message: /home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal' Despite being a large-ish change, I think it would be nice to make target_waitstatus safe against that kind of bug. As already done elsewhere (e.g. dynamic_prop), validate that the type of value read from the union matches what is supposed to be the active field. - Make the kind and value of target_waitstatus private. - Make the kind initialized to TARGET_WAITKIND_IGNORE on target_waitstatus construction. This is what most users appear to do explicitly. - Add setters, one for each kind. Each setter takes as a parameter the data associated to that kind, if any. This makes it impossible to forget to attach the associated data. - Add getters, one for each associated data type. Each getter validates that the data type fetched by the user matches the wait status kind. - Change "integer" to "exit_status", "related_pid" to "child_ptid", just because that's more precise terminology. - Fix all users. That last point is semi-mechanical. There are a lot of obvious changes, but some less obvious ones. For example, it's not possible to set the kind at some point and the associated data later, as some users did. But in any case, the intent of the code should not change in this patch. This was tested on x86-64 Linux (unix, native-gdbserver and native-extended-gdbserver boards). It was built-tested on x86-64 FreeBSD, NetBSD, MinGW and macOS. The rest of the changes to native files was done as a best effort. If I forgot any place to update in these files, it should be easy to fix (unless the change happens to reveal an actual bug). Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
2021-07-23gdb: make inferior::m_args an std::stringSimon Marchi1-6/+4
With the current code, both a NULL pointer and an empty string can mean "no arguments". We don't need this distinction. Changing to a string has the advantage that there is now a single state for that (an empty string), which makes the code a bit simpler in my opinion. Change-Id: Icdc622820f7869478791dbaa84b4a1c7fec21ced
2021-07-23gdb: add setter/getter for inferior argumentsSimon Marchi1-1/+1
Add args/set_args to the inferior class, remove the set_inferior_args and get_inferior_args functions, that would just be wrappers around them. Change-Id: If87d52f3402ce08be26c32897ae8915d9f6d1ea3
2021-07-14[gdb/procfs.c] Fix build failure in find_stop_signalLibor Bukata1-2/+2
It fixes a regression caused by commit 1edb66d856c82c389edfd7610143236a68c76846 where thread_info::suspend was made private. The public thread_info API has to be used to get stop signal and avoid build failures. gdb/ChangeLog: 2021-07-14 Libor Bukata <libor.bukata@oracle.com> * gdb/procfs.c (find_stop_signal): Use thread_info API. Change-Id: I53bc57a05cd0eca5f28ef0726d6faeeb306e7904
2021-06-17Move scoped_ignore_sigttou to gdbsupport/Pedro Alves1-1/+0
A following patch will want to use scoped_ignore_sigttou in code shared between GDB and GDBserver. Move it under gdbsupport/. Note that despite what inflow.h/inflow.c's first line says, inflow.c is no longer about ptrace, it is about terminal management. Some other files were unnecessarily including inflow.h, I guess a leftover from the days when inflow.c really was about ptrace. Those inclusions are simply dropped. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * Makefile.in (HFILES_NO_SRCDIR): Remove inflow.h. * inf-ptrace.c, inflow.c, procfs.c: Don't include "inflow.h". * inflow.h: Delete, moved to gdbsupport/ under a different name. * ser-unix.c: Don't include "inflow.h". Include "gdbsupport/scoped_ignore_sigttou.h". gdbsupport/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * scoped_ignore_sigttou.h: New file, moved from gdb/ and renamed. Change-Id: Ie390abf42c3a78bec6d282ad2a63edd3e623559a
2021-03-29Restore procfs.c compilationRainer Orth1-2/+4
Since c8fbd44a018a9923f906bfd2be5489caa87b602a (gdb: remove target_is_pushed free function), procfs.c compilation is broken, which went unnoticed for lack of functioning buildbots: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function 'virtual void procfs_target::attach(const char*, int)': /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:1772:8: error: 'inf' was not declared in this scope; did you mean 'info'? 1772 | if (!inf->target_is_pushed (this)) | ^~~ | info /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function 'virtual void procfs_target::create_inferior(const char*, const string&, char**, int)': /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:2865:8: error: 'inf' was not declared in this scope; did you mean 'info'? 2865 | if (!inf->target_is_pushed (this)) | ^~~ | info Fixed by defining inf. Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11. 2021-03-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gdb: * procfs.c (procfs_target::attach): Define inf. Use it. (procfs_target::create_inferior): Likewise.
2021-03-24gdb: remove current_top_target functionSimon Marchi1-1/+2
The current_top_target function is a hidden dependency on the current inferior. Since I'd like to slowly move towards reducing our dependency on the global current state, remove this function and make callers use current_inferior ()->top_target () There is no expected change in behavior, but this one step towards making those callers use the inferior from their context, rather than refer to the global current inferior. gdb/ChangeLog: * target.h (current_top_target): Remove, make callers use the current inferior instead. * target.c (current_top_target): Remove. Change-Id: Iccd457036f84466cdaa3865aa3f9339a24ea001d
2021-03-23gdb: remove target_is_pushed free functionSimon Marchi1-2/+2
Same principle as the previous patches. gdb/ChangeLog: * target.h (target_is_pushed): Remove, update callers to use inferior::target_is_pushed instead. * target.c (target_is_pushed): Remove. Change-Id: I9862e6205acc65672da807cbe4b46cde009e7b9d
2021-03-23gdb: remove push_target free functionsSimon Marchi1-2/+2
Same as the previous patch, but for the push_target functions. The implementation of the move variant is moved to a new overload of inferior::push_target. gdb/ChangeLog: * target.h (push_target): Remove, update callers to use inferior::push_target. * target.c (push_target): Remove. * inferior.h (class inferior) <push_target>: New overload. Change-Id: I5a95496666278b8f3965e5e8aecb76f54a97c185
2021-02-22gdb: push target earlier in procfs_target::attach (PR 27435)Simon Marchi1-2/+12
Since this is a GDB 9 -> 10 regression, I would like to push it to gdb-10-branch. This is a follow-up to: https://sourceware.org/pipermail/gdb-patches/2021-February/176202.html This patch fixes a segfault seen when attaching to a process on Solaris. The steps leading to the segfault are: - procfs_target::attach calls do_attach, at this point the inferior's process slot in the target stack is empty. - do_attach adds a thread with `add_thread (&the_procfs_target, ptid)` - in add_thread_silent, the passed target (&the_procfs_target) is passed to find_inferior_ptid - find_inferior_ptid returns nullptr, as there is no inferior with this ptid that has &the_procfs_target as its process target - the nullptr `inf` is passed to find_thread_ptid, which dereferences it, causing a segfault - back in procfs_target::attach, after do_attach, we push the the_procfs_target on the inferior's target stack, although we never reach this because the segfault happens before. To fix this, I think we need to do the same as is done in inf_ptrace_target::attach: push the target early and unpush it in case the attach fails (and keep it if the attach succeeds). Implement it by moving target_unpush_up to target.h, so it can be re-used here. Make procfs_target::attach use it. Note that just like is mentioned in inf_ptrace_target::attach, we should push the target before calling target_pid_to_str, so that calling target_pid_to_str ends up in procfs_target::pid_to_str. Tested by trying to attach on a process on gcc211 on the gcc compile farm. gdb/ChangeLog: PR gdb/27435 * inf-ptrace.c (struct target_unpusher): Move to target.h. (target_unpush_up): Likewise. * procfs.c (procfs_target::attach): Push target early. Use target_unpush_up to unpush target in case of error. * target.h (struct target_unpusher): Move here. (target_unpush_up): Likewise. Change-Id: I88aff8b20204e1ca1d792e27ac6bc34fc1aa0d52
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-10-22gdb: make target_ops::make_corefile_notes return a unique ptrSimon Marchi1-43/+45
Since we converted gdbarch_make_corefile_notes to returning a gdb::unique_xmalloc_ptr, I figured it would make sense to converted target_ops::make_corefile_notes as well. The only implementation of that is in procfs.c, and it should ideally be re-written as a gdbarch method (see comment in write_gcore_file_1), but in the mean time I guess it doesn't hurt to throw some unique pointer at it. I tested that it builds on Solaris 11 (gcc compile farm machine gcc211), but I am not able to test it, because I can't get GDB to start a process (I'll look at that separately). gdb/ChangeLog: * target.h (struct target_ops) <make_corefile_notes>: Change return type to unique pointer. * target.c (dummy_make_corefile_notes): Likewise. * exec.c (struct exec_target) <make_corefile_notes>: Likewise. (exec_target::make_corefile_notes): Likewise. * procfs.c (class procfs_target) <make_corefile_notes>: Likewise. (procfs_do_thread_registers): Adjust to unique pointer. (struct procfs_corefile_thread_data): Add constructor. <note_data>: Change type to unique pointer. (procfs_corefile_thread_callback): Adjust to unique pointer. (procfs_target::make_corefile_notes): Change return type to unique pointer. * target-delegates.c: Re-generate. * gcore.c (write_gcore_file_1): Adjust. * target-debug.h (target_debug_print_gdb_unique_xmalloc_ptr_char): New. Change-Id: I768fb17ac0f7adc67d2fe95e952c784fe0ac37ab
2020-10-02gdb: fix some inferior_created observer signaturesSimon Marchi1-9/+0
I just noticed that in a7aba2668a7b ("gdb: remove arguments from inferior_created observable"), I forgot to update aix_thread_inferior_created and procfs_inferior_created, which are in files I can't compile. Remove the parameters from aix_thread_inferior_created. And simply remove procfs_inferior_created, since it's empty anyway. gdb/ChangeLog: * aix-thread.c (aix_thread_inferior_created): Remove parameters. * procfs.c (procfs_inferior_created): Remove. (_initialize_procfs): Don't register procfs_inferior_created. Change-Id: Ifc7def7c096332033b5d466d32cb873d1df18c2c
2020-09-28Turn target_have_steppable_watchpoint into functionTom Tromey1-1/+1
This changes the object-like macro target_have_steppable_watchpoint into an inline function. gdb/ChangeLog 2020-09-28 Tom Tromey <tom@tromey.com> * infrun.c (displaced_step_fixup, thread_still_needs_step_over) (handle_signal_stop): Update. * procfs.c (procfs_target::insert_watchpoint): Update. * target.h (target_have_steppable_watchpoint): Now a function.
2020-09-18Make target_wait options use enum flagsTom Tromey1-2/+2
This changes TARGET_WNOHANG to be a member of an enum, rather than a define, and also adds a DEF_ENUM_FLAGS_TYPE for this type. Then, it changes target_wait and the various target wait methods to use this type rather than "int". This didn't catch any bugs, but it seems like a decent cleanup nevertheless. I did not change deprecated_target_wait_hook, since that's only used out-of-tree (by Insight), and there didn't seem to be a need. I can't build some of these targets, so I modified them on a best-effort basis. I don't think this patch should go in before the release branch is made. gdb/ChangeLog 2020-09-18 Tom Tromey <tromey@adacore.com> * windows-nat.c (struct windows_nat_target) <wait>: Update. (windows_nat_target::wait): Update. * target/wait.h (enum target_wait_flag): New. Use DEF_ENUM_FLAGS_TYPE. * target/target.h (target_wait): Change type of options. * target.h (target_options_to_string, default_target_wait): Update. (struct target_ops) <wait>: Change type of options. * target.c (target_wait, default_target_wait, do_option): Change type of "options". (target_options_to_string): Likewise. * target-delegates.c: Rebuild. * target-debug.h (target_debug_print_target_wait_flags): Rename from target_debug_print_options. * sol-thread.c (class sol_thread_target) <wait>: Update. (sol_thread_target::wait): Update. * rs6000-nat.c (class rs6000_nat_target) <wait>: Update. (rs6000_nat_target::wait): Update. * remote.c (class remote_target) <wait, wait_ns, wait_as>: Update. (remote_target::wait_ns, remote_target::wait_as): Change type of "options". (remote_target::wait): Update. * remote-sim.c (struct gdbsim_target) <wait>: Update. (gdbsim_target::wait): Update. * record-full.c (class record_full_base_target) <wait>: Update. (record_full_wait_1): Change type of "options". (record_full_base_target::wait): Update. * record-btrace.c (class record_btrace_target) <wait>: Update. (record_btrace_target::wait): Update. * ravenscar-thread.c (struct ravenscar_thread_target) <wait>: Update. (ravenscar_thread_target::wait): Update. * procfs.c (class procfs_target) <wait>: Update. (procfs_target::wait): Update. * obsd-nat.h (class obsd_nat_target) <wait>: Update. * obsd-nat.c (obsd_nat_target::wait): Update. * nto-procfs.c (struct nto_procfs_target) <wait>: Update. (nto_procfs_target::wait): Update. * nbsd-nat.h (struct nbsd_nat_target) <wait>: Update. * nbsd-nat.c (nbsd_wait): Change type of "options". (nbsd_nat_target::wait): Update. * linux-thread-db.c (class thread_db_target) <wait>: Update. (thread_db_target::wait): Update. * linux-nat.h (class linux_nat_target) <wait>: Update. * linux-nat.c (linux_nat_target::wait): Update. (linux_nat_wait_1): Update. * infrun.c (do_target_wait_1, do_target_wait): Change type of "options". * inf-ptrace.h (struct inf_ptrace_target) <wait>: Update. * inf-ptrace.c (inf_ptrace_target::wait): Update. * go32-nat.c (struct go32_nat_target) <wait>: Update. (go32_nat_target::wait): Update. * gnu-nat.h (struct gnu_nat_target) <wait>: Update. * gnu-nat.c (gnu_nat_target::wait): Update. * fbsd-nat.h (class fbsd_nat_target) <wait>: Update. * fbsd-nat.c (fbsd_nat_target::wait): Update. * darwin-nat.h (class darwin_nat_target) <wait>: Update. * darwin-nat.c (darwin_nat_target::wait): Update. * bsd-uthread.c (struct bsd_uthread_target) <wait>: Update. (bsd_uthread_target::wait): Update. * aix-thread.c (class aix_thread_target) <wait>: Update. (aix_thread_target::wait): Update. gdbserver/ChangeLog 2020-09-18 Tom Tromey <tromey@adacore.com> * netbsd-low.h (class netbsd_process_target) <wait>: Update. * netbsd-low.cc (netbsd_waitpid, netbsd_wait) (netbsd_process_target::wait): Change type of target_options. * win32-low.h (class win32_process_target) <wait>: Update. * win32-low.cc (win32_process_target::wait): Update. * target.h (class process_stratum_target) <wait>: Update. (mywait): Update. * target.cc (mywait, target_wait): Change type of "options". * linux-low.h (class linux_process_target) <wait, wait_1>: Update. * linux-low.cc (linux_process_target::wait) (linux_process_target::wait_1): Update.
2020-07-30Unify Solaris procfs and largefile handlingRainer Orth1-2/+0
GDB currently doesn't build on 32-bit Solaris: * On Solaris 11.4/x86: In file included from /usr/include/sys/procfs.h:26, from /vol/src/gnu/gdb/hg/master/dist/gdb/i386-sol2-nat.c:24: /usr/include/sys/old_procfs.h:31:2: error: #error "Cannot use procfs in the large file compilation environment" #error "Cannot use procfs in the large file compilation environment" ^~~~~ * On Solaris 11.3/x86 there are several more instances of this. The interaction between procfs and large-file support historically has been a royal mess on Solaris: * There are two versions of the procfs interface: ** The old ioctl-based /proc, deprecated and not used any longer in either gdb or binutils. ** The `new' (introduced in Solaris 2.6, 1997) structured /proc. * There are two headers one can possibly include: ** <procfs.h> which only provides the structured /proc, definining _STRUCTURED_PROC=1 and then including ... ** <sys/procfs.h> which defaults to _STRUCTURED_PROC=0, the ioctl-based /proc, but provides structured /proc if _STRUCTURED_PROC == 1. * procfs and the large-file environment didn't go well together: ** Until Solaris 11.3, <sys/procfs.h> would always #error in 32-bit compilations when the large-file environment was active (_FILE_OFFSET_BITS == 64). ** In both Solaris 11.4 and Illumos, this restriction was lifted for structured /proc. So one has to be careful always to define _STRUCTURED_PROC=1 when testing for or using <sys/procfs.h> on Solaris. As the errors above show, this isn't always the case in binutils-gdb right now. Also one may need to disable large-file support for 32-bit compilations on Solaris. config/largefile.m4 meant to do this by wrapping the AC_SYS_LARGEFILE autoconf macro with appropriate checks, yielding ACX_LARGEFILE. Unfortunately the macro doesn't always succeed because it neglects the _STRUCTURED_PROC part. To make things even worse, since GCC 9 g++ predefines _FILE_OFFSET_BITS=64 on Solaris. So even if largefile.m4 deciced not to enable large-file support, this has no effect, breaking the gdb build. This patch addresses all this as follows: * All tests for the <sys/procfs.h> header are made with _STRUCTURED_PROC=1, the definition going into the various config.h files instead of having to make them (and sometimes failing) in the affected sources. * To cope with the g++ predefine of _FILE_OFFSET_BITS=64, -U_FILE_OFFSET_BITS is added to various *_CPPFLAGS variables. It had been far easier to have just #undef _FILE_OFFSET_BITS in config.h, but unfortunately such a construct in config.in is commented by config.status irrespective of indentation and whitespace if large-file support is disabled. I found no way around this and putting the #undef in several global headers for bfd, binutils, ld, and gdb seemed way more invasive. * Last, the applicability check in largefile.m4 was modified only to disable largefile support if really needed. To do so, it checks if <sys/procfs.h> compiles with _FILE_OFFSET_BITS=64 defined. If it doesn't, the disabling only happens if gdb exists in-tree and isn't disabled, otherwise (building binutils from a tarball), there's no conflict. What initially confused me was the check for $plugins here, which originally caused the disabling not to take place. Since AC_PLUGINGS does enable plugin support if <dlfcn.h> exists (which it does on Solaris), the disabling never happened. I could find no explanation why the linker plugin needs large-file support but thought it would be enough if gld and GCC's lto-plugin agreed on the _FILE_OFFSET_BITS value. Unfortunately, that's not enough: lto-plugin uses the simple-object interface from libiberty, which includes off_t arguments. So to fully disable large-file support would mean also disabling it in libiberty and its users: gcc and libstdc++-v3. This seems highly undesirable, so I decided to disable the linker plugin instead if large-file support won't work. The patch allows binutils+gdb to build on i386-pc-solaris2.11 (both Solaris 11.3 and 11.4, using GCC 9.3.0 which is the worst case due to predefined _FILE_OFFSET_BITS=64). Also regtested on amd64-pc-solaris2.11 (again on Solaris 11.3 and 11.4), x86_64-pc-linux-gnu and i686-pc-linux-gnu. config: * largefile.m4 (ACX_LARGEFILE) <sparc-*-solaris*|i?86-*-solaris*>: Check for <sys/procfs.h> incompatilibity with large-file support on Solaris. Only disable large-file support and perhaps plugins if needed. Set, substitute LARGEFILE_CPPFLAGS if so. bfd: * bfd.m4 (BFD_SYS_PROCFS_H): New macro. (BFD_HAVE_SYS_PROCFS_TYPE): Require BFD_SYS_PROCFS_H. Don't define _STRUCTURED_PROC. (BFD_HAVE_SYS_PROCFS_TYPE_MEMBER): Likewise. * elf.c [HAVE_SYS_PROCFS_H] (_STRUCTURED_PROC): Don't define. * configure.ac: Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>. * configure, config.in: Regenerate. * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. binutils: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. * configure: Regenerate. gas: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in, doc/Makefile.in: Regenerate. * configure: Regenerate. gdb: * proc-api.c (_STRUCTURED_PROC): Don't define. * proc-events.c: Likewise. * proc-flags.c: Likewise. * proc-why.c: Likewise. * procfs.c: Likewise. * Makefile.in (INTERNAL_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * configure, config.in: Regenerate. gdbserver: * configure, config.in: Regenerate. gdbsupport: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * common.m4 (GDB_AC_COMMON): Use BFD_SYS_PROCFS_H to check for <sys/procfs.h>. * Makefile.in: Regenerate. * configure, config.in: Regenerate. gnulib: * configure.ac: Run ACX_LARGEFILE before gl_EARLY. * configure: Regenerate. gprof: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in: Regenerate. * configure: Regenerate. ld: * Makefile.am (AM_CPPFLAGS): Add LARGEFILE_CPPFLAGS. * Makefile.in: Regenerate. * configure: Regenerate.
2020-06-25Use fork instead of vfork on SolarisRainer Orth1-1/+8
The gdb.mi/mi-exec-run.exp test never completed/timed out on Solaris for quite some time: FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected (timeout) This is for gdb trying to exec mi-exec-run.nox, a copy of mi-exec-run with execute permissions removed. The process tree at this point looks like this: 21254 /vol/gcc/bin/expect -- /vol/gcc/share/dejagnu/runtest.exp GDB_PARALLEL=yes --outdir=outputs/gdb.mi/mi-exec-run-vfork gdb.mi/mi-exec-run.exp 21300 <defunct> 21281 <defunct> 21294 $obj/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory $obj/gdb/testsuite/../data-directory -i=mi 21297 $obj/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory $obj/gdb/testsuite/../data-directory -i=mi The parent gdb hangs here: 21294: $obj/gdb/testsuite/../../gdb/gdb -nw ------------ lwp# 1 / thread# 1 --------------- 0000000000000000 SYS#0 () 0000000000daeccd procfs_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int) () + 97 (procfs.c:2853) 0000000000ca63a7 run_command_1(char const*, int, run_how) () + 349 (basic_string.h:187) 0000000000ca6516 start_command(char const*, int) () + 26 (infcmd.c:584) 0000000000b3ca8e do_const_cfunc(cmd_list_element*, char const*, int) () + f (cli-decode.c:96) 0000000000b3ed77 cmd_func(cmd_list_element*, char const*, int) () + 32 (cli-decode.c:2113) 0000000000f2d219 execute_command(char const*, int) () + 455 (top.c:657) 0000000000d4ad77 mi_execute_cli_command(char const*, int, char const*) () + 242 (basic_string.h:187) 0000000000d4ae80 mi_cmd_exec_run(char const*, char**, int) () + ba (mi-main.c:473) with these process flags 21294: $obj/gdb/testsuite/../../gdb/gdb -nw data model = _LP64 flags = VFORKP|ORPHAN|MSACCT|MSFORK sigpend = 0x00004103,0x00000000,0x00000000 /1: flags = 0 sigmask = 0xffbffeff,0xffffffff,0x000000ff cursig = SIGKILL /2: flags = DETACH|STOPPED|ASLEEP lwp_park(0x0,0x0,0x0) why = PR_SUSPENDED sigmask = 0x000a2002,0x00000000,0x00000000 [...] while the child sits at 21297: $obj/gdb/testsuite/../../gdb/gdb -nw 00007fffbf078a0b execve (7fffbffff756, 7fffbfffec58, 7fffbfffec90, 0) 00007fffbef84cf6 execvpex () + f6 00007fffbef84f45 execvp () + 15 0000000000d60a44 fork_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, void (*)(), gdb::function_view<void (int)>, void (*)(), char const*, void (*)(char const*, char* const*, char* const*)) () + 47f (fork-inferior.c:423) 0000000000daeccd procfs_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int) () + 97 (procfs.c:2853) 0000000000ca63a7 run_command_1(char const*, int, run_how) () + 349 (basic_string.h:187) 0000000000ca6516 start_command(char const*, int) () + 26 (infcmd.c:584) 0000000000b3ca8e do_const_cfunc(cmd_list_element*, char const*, int) () + f (cli-decode.c:96) 0000000000b3ed77 cmd_func(cmd_list_element*, char const*, int) () + 32 (cli-decode.c:2113) 0000000000f2d219 execute_command(char const*, int) () + 455 (top.c:657) 0000000000d4ad77 mi_execute_cli_command(char const*, int, char const*) () + 242 (basic_string.h:187) 0000000000d4ae80 mi_cmd_exec_run(char const*, char**, int) () + ba (mi-main.c:473) with 21297: $obj/gdb/testsuite/../../gdb/gdb -nw data model = _LP64 flags = MSACCT|MSFORK exitset = 0x00000000 0x04000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 /1: flags = STOPPED|ISTOP execve(0x7fffbffff756,0x7fffbfffec58,0x7fffbfffec90,0x0) why = PR_SYSEXIT what = execve We have a deadlock here: the execve in the child cannot return until the parent has handled the PR_SYSEXIT while the parent cannot run with a vfork'ed child as documented in proc(4): The child of a vfork(2) borrows the parent's address space. When a vfork(2) is executed by a traced process, all watched areas established for the parent are suspended until the child terminates or performs an exec(2). Any watched areas established independently in the child are cancelled when the parent resumes after the child's termination or exec(2). PCWATCH fails with EBUSY if applied to the parent of a vfork(2) before the child has terminated or performed an exec(2). The PR_VFORKP flag is set in the pstatus structure for such a parent process. In that situation, the parent cannot be killed even with SIGKILL (as runtest will attempt once the timeout occurs; the pending signal can be seen in the pflags output above), so the whole test hangs until one manually kills the child process. Fortunately, there's an easy way out: when using fork instead of vfork, the problem doesn't occur, and this is what the current patch does: it calls fork_inferior with a dummy pre_trace_fun arg. Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11. * procfs.c (procfs_pre_trace): New function. (procfs_target::create_inferior): Pass it to fork_inferior.
2020-06-22Solaris, target_wait(), don't rely on inferior_ptidPedro Alves1-28/+17
Debugging on Solaris is broken, with the procfs target backend failing with: procfs: couldn't find pid 0 in procinfo list. as soon as you start a program. The problem is procfs_target::wait assuming that inferior_ptid is meaningful on entry, but, since the multi-target series, inferior_ptid is null_ptid before we call target_wait, in infrun.c: static ptid_t do_target_wait_1 (inferior *inf, ptid_t ptid, target_waitstatus *status, int options) { ... /* We know that we are looking for an event in the target of inferior INF, but we don't know which thread the event might come from. As such we want to make sure that INFERIOR_PTID is reset so that none of the wait code relies on it - doing so is always a mistake. */ switch_to_inferior_no_thread (inf); This patch tweaks the backend to remove the assumption that inferior_ptid points at something. sol-thread.c (the thread_stratum that sits on top of procfs.c) also has the same issue. Some spots in procfs_target::wait were returning TARGET_WAITKIND_SPURIOUS+inferior_ptid. This commit replaces those with waiting again without returning to the core. This fixes the relying on inferior_ptid, and also should fix the issue discussed here: https://sourceware.org/pipermail/gdb/2020-May/048616.html https://sourceware.org/pipermail/gdb/2020-June/048660.html gdb/ChangeLog: 2020-06-22 Pedro Alves <palves@redhat.com> PR gdb/25939 * procfs.c (procfs_target::wait): Don't reference inferior_ptid. Use the current inferior instead. Don't return TARGET_WAITKIND_SPURIOUS/inferior_ptid -- instead continue and wait again. * sol-thread.c (sol_thread_target::wait): Don't reference inferior_ptid. (ps_lgetregs, ps_lsetregs, ps_lgetfpregs, ps_lsetfpregs) (sol_update_thread_list_callback): Use the current inferior's pid instead of inferior_ptid.
2020-06-21Various procfs.c cleanupsRainer Orth1-175/+28
While reading through procfs.c, I noticed a couple of cleanup opportunities: * Some comments and code allowed for portability across different targets. Since procfs.c is Solaris-only for some time now, those can go. * Likewise, there were some references to the old ioctl-based /proc left. * The code still allowed for SYS_exec. However, it is no longer present in either Solaris 11.3, 11.4, or Illumos. Checking the OpenSolaris sources, I found that it had already been removed in 2010 well before the Solaris 11 release. * Some blocks of #if 0 code can go: ** References to struct procinfo.{g,fp}regs_dirty which are no longer defined. ** Code handling the PR_ASLWP flag where <sys/procfs.h> has #define PR_ASLWP 0x00000040 /* obsolete flag; never set */ Tested on amd64-pc-solaris2.11. * procfs.c: Cleanup many comments. (READ_WATCHFLAG, WRITE_WATCHFLAG, EXEC_WATCHFLAG) (AFTER_WATCHFLAG): Replace by value. (MAIN_PROC_NAME_FORMAT): Inline ... (create_procinfo): ... here. (procfs_debug_inferior): Remove SYS_exec handling. (syscall_is_exec): Likewise. (procfs_set_exec_trap): Likewise. (syscall_is_lwp_exit): Inline in callers. (syscall_is_exit): Likewise. (syscall_is_exec): Likewise. (syscall_is_lwp_create): Likewise. (invalidate_cache): Remove #if 0 code. (make_signal_thread_runnable): Remove. (procfs_target::resume): Remove #if 0 code.
generated by cgit v1.1 at 2024-08-17 12:38:32 +0000