This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
This commit changes how gdbserver stores the inferior arguments from
being a vector of separate arguments into a single string with all of
the arguments combined together.
Making this change might feel a little strange; intuitively it feels
like we would be better off storing the arguments as a vector, but
this change is part of a larger series of work that aims to improve
GDB's inferior argument handling. The full series was posted here:
https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com
But asking people to review a 14 patch series in unreasonable, so I'm
instead posting the patches in smaller batches. This patch can stand
alone, and I do think this change makes sense on its own:
First, GDB already stores the inferior arguments as a single string,
so doing this moves gdbserver into line with GDB. The common code
into which gdbserver calls requires the arguments to be a single
string, so currently each target's create_inferior implementation
merged the arguments anyway, so all this commit really does is move
the merging up the call stack, and store the merged result rather than
storing the separate parts.
However, the biggest reason for why this commit is needed, is an issue
with passing arguments from GDB to gdbserver when starting a new
inferior.
Consider:
(gdb) set args $VAR
(gdb) run
...
When using a native target the inferior will see the value of $VAR
expanded by the shell GDB uses to start the inferior. However, if
using an extended-remote target the inferior will see literally $VAR,
the unexpanded name of the variable, the reason for this is that,
although GDB sends '$VAR' to gdbserver, when gdbserver receives this,
it converts this to '\$VAR', which prevents the variable from being
expanded by the shell.
The reason for this is that construct_inferior_arguments escapes all
special shell characters within its arguments, and it is
construct_inferior_arguments that is used to combine the separate
arguments into a single string.
In the future I will change construct_inferior_arguments so that
it can apply different escaping strategies. When this happens we will
want to escape arguments coming from the gdbserver command line
differently than arguments coming from GDB (via a vRun packet), which
means we need to call construct_inferior_arguments earlier, at the
point where we know if the arguments came from the gdbserver command
line, or from the vRun packet.
This argument escaping issue is discussed in PR gdb/28392.
This commit doesn't fix any issues, nor does it change
construct_inferior_arguments to actually do different escaping, that
will all come later. This is purely a restructuring.
There should be no user visible changes after this commit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392
Tested-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Boolify the 'fetch' parameter of the get_thread_regcache function.
All of the current uses pass true for this parameter. Therefore, define
its default value as true and remove the argument from the uses.
We still keep the parameter, though, to give downstream targets the
option to obtain a regcache without having to fetch the whole
contents. Our (Intel) downstream target is an example.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In the spirit of encapsulation, I'm looking to remove the need for
external code to access the "ptid -> thread" map of process_info, making
it an internal implementation detail. The only remaining use is in
function clear_inferiors, and it led me down this rabbit hole:
- clear_inferiors is really only used by the Windows port and doesn't
really make sense in the grand scheme of things, I think (when would
you want to remove all threads of all processes, without removing
those processes?)
- ok, so let's remove clear_inferiors and inline the code where it's
called, in function win32_clear_inferiors
- the Windows port does not support multi-process, so it's not really
necessary to loop over all processes like this:
for_each_process ([] (process_info *process)
{
process->thread_list ().clear ();
process->thread_map ().clear ();
});
We could just do:
current_process ()->thread_list ().clear ();
current_process ()->thread_map ().clear ();
(or pass down the process from the caller, but it's not important
right now)
- so, the code that we've inlined in win32_clear_inferiors does 3
things:
- clear the process' thread list and map (which deletes the
thread_info objects)
- clear the dll list, which just basically frees some objects
- switch to no current process / no current thread
- let's now look at where this win32_clear_inferiors function is used:
- in win32_process_target::kill, where the process is removed just
after
- in win32_process_target::detach, where the process is removed
just after
- in win32_process_target::wait, when handling a process exit.
After this returns, we could be in handle_target_event (if async)
or resume (if sync), both in `server.cc`. In both of these
cases, target_mourn_inferior gets called, we end up in
win32_process_target::mourn, which removes the process
- in all 3 cases above, we end up removing the process, which takes
care of the 3 actions listed above:
- the thread list and map get cleared when the process gets
destroyed
- same with the dll list
- remove_process switches to no current process / current thread
if the process being removed is the current one
- I conclude that it's probably unnecessary to do the cleanup in
win32_clear_inferiors, because it's going to get done right after
anyway.
Therefore, this patch does:
- remove clear_inferiors, remove the call in win32_clear_inferiors
- remove clear_dlls, which is now unused
- remove process_info::thread_map, which is now unused
- rename win32_clear_inferiors to win32_clear_process, which seems more
accurate
win32_clear_inferiors also does:
for_each_thread (delete_thread_info);
which also makes sure to delete all threads, but it also deletes the
Windows private data object (windows_thread_info), so I'll leave this
one there for now. But if we could make the thread private data
destruction automatic, on thread destruction, it could be removed, I
think.
There should be no user-visible change with this patch. Of course,
operations don't happen in the same order as before, so there might be
some important detail I'm missing. I'm only able to build-test this, if
someone could give it a test run on Windows, it would be appreciated.
Change-Id: I4a560affe763a2c965a97754cc02f3083dbe6fbf
Currently we have duplicate code for each place where
windows_thread_info::context is touched, since for WOW64 processes
it has to do the equivalent with wow64_context instead.
For example this code...:
#ifdef __x86_64__
if (windows_process.wow64_process)
{
th->wow64_context.ContextFlags = WOW64_CONTEXT_ALL;
CHECK (Wow64GetThreadContext (th->h, &th->wow64_context));
...
}
else
#endif
{
th->context.ContextFlags = CONTEXT_DEBUGGER_DR;
CHECK (GetThreadContext (th->h, &th->context));
...
}
...changes to look like this instead:
windows_process.with_context (th, [&] (auto *context)
{
context->ContextFlags = WindowsContext<decltype(context)>::all;
CHECK (get_thread_context (th->h, context));
...
}
The actual choice if context or wow64_context are used, is handled by
this new function in windows_process_info:
template<typename Function>
auto with_context (windows_thread_info *th, Function function)
{
#ifdef __x86_64__
if (wow64_process)
return function (th != nullptr ? th->wow64_context : nullptr);
else
#endif
return function (th != nullptr ? th->context : nullptr);
}
The other parts to make this work are the templated WindowsContext class
which give the appropriate ContextFlags for both types.
And there are also overloaded helper functions, like in the case of
get_thread_context here, call either GetThreadContext or
Wow64GetThreadContext.
According git log --stat, this results in 120 lines less code.
Approved-By: Tom Tromey <tom@tromey.com>
Fix this:
gdbserver/win32-low.cc: In function ‘void child_delete_thread(DWORD, DWORD)’:
gdbserver/win32-low.cc:192:7: error: ‘all_threads’ was not declared in this scope; did you mean ‘using_threads’?
192 | if (all_threads.size () == 1)
| ^~~~~~~~~~~
| using_threads
Commit 9f77b3aa0b ("gdbserver: change 'all_processes' and
'all_threads' list type") changed the type of `all_thread` to an
intrusive_list, without changing this particular use, which broke the
build because an intrusive_list doesn't know its size, so it doesn't
have a `size()` method. The subsequent commit removed `all_threads`,
leading to the error above.
Fix it by using the number of threads of the concerned process instead.
My rationale: as far as I know, GDBserver on Windows only supports one
process at a time, so there's no need to iterate over all processes. If
we made GDBserver for Windows support multiple processes, my intuition
is that we'd want this check to use the number of threads of the
concerned process, not the number of threads overall.
Add the method `process_info::thread_count`, to get the number of
threads of the process.
I'm not really sure what this check is for in the first place, Hannes
Domani said that this check didn't seem to trigger on Windows 7 and 11.
Perhaps it was necessary before.
Change-Id: I84d6226532b887d99248cf3be90f5065fb7a074a
Tested-By: Hannes Domani <ssbssa@yahoo.de>
Make the field private, change the free function to be a method.
Change-Id: I05010e7d1bd58ce3895802eb263c029528427758
Approved-By: Tom Tromey <tom@tromey.com>
This function doesn't seem so useful. Use `thread_info::id` directly.
Change-Id: I4ae4e7baa44e09704631a1c3a5a66e5b8b5a3594
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
I think it just makes things more obscure. Use `thread_info::id`
directly instead.
Change-Id: I141d5fb08ebf45c13cc32c4bba62773249fcb356
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Same idea as the previous patch, but for `remove_thread`.
Change-Id: I7e227655be5fcf29a3256e8389eb32051f27882d
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Since thread_info objects are now basically children of process_info
objects, I think that makes sense.
Change-Id: I7f0a67b921b468e512851cb2f36015d1003412d7
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Like the previous commit, add two overloads of gdb_tilde_expand, one
takes std::string and other takes gdb::unique_xmalloc_ptr<char>. Make
use of these overloads throughout GDB and gdbserver.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
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>
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.
this patch fixes a crash in gdbserver whenever a process is detached.
the crash is caused by `detach` calling `remove_process` before `win32_clear_inferiors`
error message:
Detaching from process 184
../../gdbserver/inferiors.cc:160: A problem internal to GDBserver has been detec
ted.
remove_process: Assertion `find_thread_process (process) == NULL' failed.
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Approved-By: Tom Tromey <tom@tromey.com>
I noticed that gdbserver/win32-low.cc has a fall-through comment that
should have been converted to use the annotation instead.
This patch makes the change.
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>
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.
I don't see why include/gdb/fileio.h is placed there. It's not
installed by "make install", and it's not included by anything outside
of gdb/gdbserver/gdbsupport.
Move its content back to gdbsupport/fileio.h. I have omitted the bits
inside an `#if 0`, since it's obviously not used, as well as the
"limits" constants, which are also unused.
Change-Id: I6fbc2ea10fbe4cfcf15f9f76006b31b99c20e5a9
When working on windows-nat.c, it's useful to see an error message in
addition to the error number given by GetLastError. This patch moves
strwinerror from gdbserver to gdbsupport, and then updates
windows-nat.c to use it. A couple of minor changes to strwinerror
(constify the return type and use the ARRAY_SIZE macro) are also
included.
This changes windows_process_info to use virtual methods for its
callbacks, and then changes the two clients of this code to subclass
this class to implement the methods.
I considered using CRTP here, but that would require making the new
structures visible to the compilation of of nat/windows-nat.c. This
seemed like a bit of a pain, so I didn't do it.
This change then lets us change all the per-inferior globals to be
members of the new subclass. Note that there can still only be a
single inferior -- currently there's a single global of the new type.
This is just another step toward possibly implementing multi-inferior
for Windows.
It's possible this could be cleaned up further... ideally I'd like to
move more of the data into the base class. However, because gdb
supports Cygwin and gdbserver does not, and because I don't have a way
to build or test Cygwin, larger refactorings are difficult.
On Windows, it is possible to disable ASLR when creating a process.
This patch adds code to do this, and hooks it up to gdb's existing
disable-randomization feature. Because the Windows documentation
cautions that this isn't available on all versions of Windows, the
CreateProcess wrapper function is updated to make the attempt, and
then fall back to the current approach if it fails.
I noticed that gdbserver did not implement pid_to_exec_file for
Windows, while gdb did implement it. This patch moves the code to
nat/windows-nat.c, so that it can be shared. This makes the gdbserver
implementation trivial.
I broke the gdbserver build on x86-64 Windows a little while back.
Previously, I could not build this configuration, but today I found
out that if I configure with:
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
using the Fedora 34 tools, it will in fact build. I'm not certain,
but maybe the gnulib update helped with this.
This patch fixes the build. I'm checking it in.
Windows 10 introduced SetThreadDescription and GetThreadDescription, a
simpler way to set a thread's name. This changes gdb and gdbserver to
use this convention when it is available.
This is part of PR win32/29050.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29050
Currently, gdb's native Windows target implements the exception-based
approach for setting thread names, but gdbserver does not. This patch
moves handle_ms_vc_exception to the shared nat/windows-nat.c code, as
preparation for adding this support to gdbserver.
nat/windows-nat.c has a number of globals that it uses to communicate
with its clients (gdb and gdbserver). However, if we ever want the
Windows ports to be multi-inferior, globals won't work.
This patch takes a step toward that by moving most nat/windows-nat.c
globals into a new struct windows_process_info. Many functions are
converted to be methods on this object.
A couple of globals remain, as they are needed to truly be global due
to the way that the Windows debugging APIs work.
The clients still have a global for the current process. That is,
this patch is a step toward the end goal, but doesn't implement the
goal itself.
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.
Replace the direct assignments to current_thread with
switch_to_thread. Use scoped_restore_current_thread when appropriate.
There is one instance remaining in linux-low.cc's wait_for_sigstop.
This will be handled in a separate patch.
Regression-tested on X86-64 Linux using the native-gdbserver and
native-extended-gdbserver board files.
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
This moves the new DLL-loading code into nat/windows-nat.c, and
changes both gdb and gdbserver to use the shared code. One
client-provided callback, handle_load_dll, is changed to allow the
code to be shared. This callback was actually never called from
nat/windows-nat.c; maybe I had planned to share more here and then
didn't finish... I'm not sure.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_load_dll): Update.
(windows_nat_target::get_windows_debug_event): Call
dll_loaded_event.
(windows_add_all_dlls, windows_add_dll): Move to
nat/windows-nat.c.
* nat/windows-nat.h (handle_load_dll): Change parameters.
(dll_loaded_event, windows_add_all_dlls): Declare.
* nat/windows-nat.c (windows_add_dll, windows_add_all_dlls): Move
from windows-nat.c.
(dll_loaded_event): New function.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* win32-low.cc (do_initial_child_stuff): Update.
(windows_nat::handle_load_dll): Rename from win32_add_one_solib.
Change parameter type.
(win32_add_dll, win32_add_all_dlls)
(windows_nat::handle_load_dll): Remove.
(get_child_debug_event): Call dll_loaded_event.
This changes gdbserver to use the function indirection code that was
just moved into nat/windows-nat.[ch]. One additional function is used
by gdbserver that was not used by gdb.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* nat/windows-nat.h (GenerateConsoleCtrlEvent): New define.
(GenerateConsoleCtrlEvent_ftype, GenerateConsoleCtrlEvent):
Declare.
* nat/windows-nat.c (GenerateConsoleCtrlEvent): Define.
(initialize_loadable): Initialize GenerateConsoleCtrlEvent.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* win32-low.cc (GETPROCADDRESS): Remove.
(winapi_DebugActiveProcessStop, winapi_DebugSetProcessKillOnExit)
(winapi_DebugBreakProcess, winapi_GenerateConsoleCtrlEvent)
(winapi_Wow64SetThreadContext, win32_Wow64GetThreadContext)
(win32_Wow64SetThreadContext): Remove.
(win32_set_thread_context, do_initial_child_stuff)
(win32_process_target::attach, win32_process_target::detach):
Update.
(winapi_EnumProcessModules, winapi_EnumProcessModulesEx)
(winapi_GetModuleInformation, winapi_GetModuleInformationA):
Remove.
(win32_EnumProcessModules, win32_EnumProcessModulesEx)
(win32_GetModuleInformation, win32_GetModuleInformationA):
Remove.
(load_psapi): Remove.
(win32_add_dll, win32_process_target::request_interrupt): Update.
(initialize_low): Call initialize_loadable.
This removes the one last use of _WIN32_WCE from gdbserver.
gdbserver/ChangeLog
2021-04-14 Tom Tromey <tromey@adacore.com>
* win32-low.cc (windows_nat::handle_load_dll): Don't check
_WIN32_WCE.
I noticed that gdbserver/win32-low.cc has a few typedefs that are not
used. This patch removes them.
gdbserver/ChangeLog
2021-04-13 Tom Tromey <tromey@adacore.com>
* win32-low.cc (winapi_CreateToolhelp32Snapshot)
(winapi_Module32First, winapi_Module32Next): Remove typedefs.
The support for WinCE was removed with commit 84b300de36 ("gdbserver:
remove support for ARM/WinCE"). There is some leftover code for WinCE
support, guarded by the _WIN32_WCE macro, which I didn't know of at the
time.
I didn't remove the _WIN32_WCE references in the tests, because in
theory we still support the WinCE architecture in GDB (when debugging
remotely). So someone could run a test with that (although I'd be
really surprised).
gdb/ChangeLog:
* nat/windows-nat.c: Remove all code guarded by _WIN32_WCE.
* nat/windows-nat.h: Likewise.
gdbserver/ChangeLog:
* win32-low.cc: Remove all code guarded by _WIN32_WCE.
* win32-low.h: Likewise.
Change-Id: I7a871b897e2135dc195b10690bff2a01d9fac05a
This fixes win32-low.cc in the same way as a recent change in
windows-nat.c did for GDB: if the lpImageName member of the load-DLL
debug event doesn't allow us to find the file name of the DLL, then
loop over all the DLLs mapped into the inferior to find the one loaded
at the same base address as given by the lpBaseOfDll member of the
debug event.
gdbserver/ChangeLog:
2021-04-11 Eli Zaretskii <eliz@gnu.org>
* win32-low.cc (win32_add_dll): New function, with body almost
identical to what win32_add_all_dlls did. Accepts one argument;
if that is non-NULL, returns the file name of the DLL that is
loaded at the base address equal to that argument, or NULL if not
found. If the argument is NULL, add all the DLLs loaded by the
inferior to the list of solibs and return NULL.
(win32_add_all_dlls): Now a thin wrapper around win32_add_dll.
(windows_nat::handle_load_dll) [!_WIN32_WCE]: If get_image_name
failed to glean the file name of the DLL, call win32_add_dll to
try harder using the lpBaseOfDll member of the load-DLL event.
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.
When a WOW64 process triggers a breakpoint exception in 64bit code (which
happens when a 64bit gdb calls DebugBreakProcess for a 32bit target),
gdb ignores the breakpoint (because Wow64GetThreadContext can only report
the pc of 32bit code, and there is not int3 at this location).
But if these 64bit breakpoint exceptions are handled as SIGINT, gdb
doesn't check for int3, and always stops the target.
gdb/ChangeLog:
2020-09-23 Hannes Domani <ssbssa@yahoo.de>
* nat/windows-nat.c (handle_exception): Handle 64bit breakpoints
in WOW64 processes as SIGINT.
* nat/windows-nat.h: Make wow64_process a shared variable.
* windows-nat.c: Remove static wow64_process variable.
gdbserver/ChangeLog:
2020-09-23 Hannes Domani <ssbssa@yahoo.de>
* win32-low.cc: Remove local wow64_process variable.
* win32-low.h: Remove local wow64_process variable.
Only the process handle returned by OpenProcess or CreateProcess needs to
be closed, the one provided by WaitForDebugEvent is closed automatically.
gdbserver/ChangeLog:
2020-05-27 Hannes Domani <ssbssa@yahoo.de>
* win32-low.cc (do_initial_child_stuff): Set open_process_used.
(win32_clear_inferiors): Use open_process_used.
(get_child_debug_event): Likewise.
Use the construct_inferior_arguments function instead of
stringify_argv to construct a string from the program
arguments in those places where that one is then passed
to fork_inferior (linux-low, lyn-low), since
construct_inferior_arguments properly takes care of
special characters, while stringify_argv does not.
Using construct_inferior_arguments seems "natural", since its
documentation also mentions that it "does the
same shell processing as fork_inferior".
Since construct_inferior_args has been extended to do
proper quoting for Windows shells in commit
5d60742e2d
("Fix quoting of special characters for the MinGW build.",
2012-06-12), use it for the Windows case as well.
(I could not test that case myself, though.)
Adapt handling of empty args in function 'handle_v_run'
in gdbserver/server.cc to just insert an empty string
for an empty arg, since that one is now properly handled
in 'construct_inferior_arguments' already (and inserting
a "''" string in 'handle_v_run' would otherwise
cause that one to be treated as a string literally
containing two quote characters, which
'construct_inferior_args' would preserve by adding
extra escaping).
This makes gdbserver properly handle program args containing special
characters (like spaces), e.g. (example from PR25893)
$ gdbserver localhost:50505 myprogram "hello world"
now properly handles "hello world" as a single arg, not two separate
ones ("hello", "world").
gdbserver/ChangeLog:
PR gdbserver/25893
* linux-low.cc (linux_process_target::create_inferior),
lynx-low.cc (lynx_process_target::create_inferior),
win32-low.cc (win32_process_target::create_inferior): Use
construct_inferior_arguments instead of stringify_argv
to get string representation which properly escapes
special characters.
* server.cc (handle_v_run): Just pass empty program arg
as such, since any further processing is now handled via
construct_inferior_arguments.
Change-Id: Ibf963fcd51415c948840fb463289516b3479b0c3
Simon pointed out that the windows-nat sharing series broke the Cygwin
build. This patch fixes the problem, by moving the Cygwin-specific
code to a new handler function. This approach is taken because this
code calls find_pc_partial_function, which isn't available in
gdbserver.
gdb/ChangeLog
2020-04-16 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_access_violation): New
function.
* nat/windows-nat.h (handle_access_violation): Declare.
* nat/windows-nat.c (handle_exception): Move Cygwin code to
windows-nat.c. Call handle_access_violation.
gdbserver/ChangeLog
2020-04-16 Tom Tromey <tromey@adacore.com>
* win32-low.cc (windows_nat::handle_access_violation): New
function.
