[PATCH] Specify python2 or python3 as Python program name

[PATCH] Specify python2 or python3 as Python program name

[Jim Chen]

Hi,

When initializing Python, GDB hard codes the Python program name to
$prefix/bin/python, where $prefix is /usr for example. On some
platforms, /usr/bin/python points to python3. So what happens is, even
if GDB is built with python2 support, GDB ends up setting the Python
program name to point to python3, causing a mismatch. I think it's
better to deliberately specify python2 or python3.

Patch tested on x86_64-linux.

gdb:

2016-05-05  Jim Chen <nchen@mozilla.com>

	* python/python.c (_initialize_python): Specify python2 or python3
	when initializing the Python program name.
---
 gdb/python/python.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gdb/python/python.c b/gdb/python/python.c
index c706644..4e80951 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -1701,17 +1701,23 @@ message == an error message without a stack will be printed."),
 #ifdef WITH_PYTHON_PATH
   /* Work around problem where python gets confused about where it is,
      and then can't find its libraries, etc.
      NOTE: Python assumes the following layout:
      /foo/bin/python
      /foo/lib/pythonX.Y/...
      This must be done before calling Py_Initialize.  */
   progname = concat (ldirname (python_libdir), SLASH_STRING, "bin",
-		     SLASH_STRING, "python", (char *) NULL);
+		     SLASH_STRING,
+#ifdef IS_PY3K
+		     "python3",
+#else
+		     "python2",
+#endif
+		     (char *) NULL);
 #ifdef IS_PY3K
   oldloc = xstrdup (setlocale (LC_ALL, NULL));
   setlocale (LC_ALL, "");
   progsize = strlen (progname);
   progname_copy = (wchar_t *) PyMem_Malloc ((progsize + 1) * sizeof (wchar_t));
   if (!progname_copy)
     {
       xfree (oldloc);
-- 
2.7.3

[PATCH] [GDBServer] Send SIGINT using process group ID

[Jim Chen]

Hi,

linux_request_interrupt is supposed to send SIGINT to the process group,
but it passes the process ID to kill() instead of the process group ID,
which may not be the same as the process ID. The patch calls getpgid
first to get the process group ID.

Patch tested on arm-linux.

gdb/gdbserver:

2016-05-11  Jim Chen  <nchen@mozilla.com>

	* linux-low.c (linux_request_interrupt): Use process group ID for
	sending SIGINT
---
 gdb/gdbserver/linux-low.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
index 8e1e2fc..a282ca1 100644
--- a/gdb/gdbserver/linux-low.c
+++ b/gdb/gdbserver/linux-low.c
@@ -5745,17 +5745,17 @@ linux_look_up_symbols (void)
 
 static void
 linux_request_interrupt (void)
 {
   extern unsigned long signal_pid;
 
   /* Send a SIGINT to the process group.  This acts just like the user
      typed a ^C on the controlling terminal.  */
-  kill (-signal_pid, SIGINT);
+  kill (-getpgid(signal_pid), SIGINT);
 }
 
 /* Copy LEN bytes from inferior's auxiliary vector starting at OFFSET
    to debugger memory starting at MYADDR.  */
 
 static int
 linux_read_auxv (CORE_ADDR offset, unsigned char *myaddr, unsigned int len)
 {
-- 
2.7.3

Re: [PATCH] Specify python2 or python3 as Python program name

[Eli Zaretskii]

> From: Jim Chen <nchen@mozilla.com>
> Cc: Jim Chen <nchen@mozilla.com>
> Date: Wed, 11 May 2016 17:51:46 -0400
> 
> When initializing Python, GDB hard codes the Python program name to
> $prefix/bin/python, where $prefix is /usr for example. On some
> platforms, /usr/bin/python points to python3. So what happens is, even
> if GDB is built with python2 support, GDB ends up setting the Python
> program name to point to python3, causing a mismatch. I think it's
> better to deliberately specify python2 or python3.

I have Python 2.x installed, but there's no "python2" executable
anywhere in sight, only a "python" executable.  Does this patch mean
GDB will no longer be able to invoke Python on my system?

Thanks.

Re: [PATCH] Specify python2 or python3 as Python program name

[Yao Qi]

Jim Chen <nchen@mozilla.com> writes:

> When initializing Python, GDB hard codes the Python program name to
> $prefix/bin/python, where $prefix is /usr for example. On some
> platforms, /usr/bin/python points to python3. So what happens is, even
> if GDB is built with python2 support, GDB ends up setting the Python
> program name to point to python3, causing a mismatch. I think it's

I agree that is a problem ...

> better to deliberately specify python2 or python3.

... but I don't think your patch is the right fix.  What we can do in
GDB is probably emit an error if the $prefix/bin/python is incompatible
to the python we build gdb against.

-- 
Yao (齐尧)

Re: [PATCH] [GDBServer] Send SIGINT using process group ID

[Pedro Alves]

On 05/11/2016 10:51 PM, Jim Chen wrote:
> Hi,
> 
> linux_request_interrupt is supposed to send SIGINT to the process group,
> but it passes the process ID to kill() instead of the process group ID,
> which may not be the same as the process ID. 
> The patch calls getpgid
> first to get the process group ID.
> 
> Patch tested on arm-linux.

Can you expand on the use case you see this happening on, please?
I can imagine some, but I'd like to hear it from you.

Some have expressed desire to _not_ send the SIGINT to the whole
process group, which may make sense when you're attached to a
process rather than having started it.  IIRC, there's a bug filed in 
bugzilla about this.

Looking at the code, not-sending-to-process-group-when-attached
is what native GNU/Linux does too (inflow.c:pass_signal).

Seems like "c&" -> "interrupt" doesn't consider "attach" either,
as inf-ptrace.c:inf_ptrace_interrupt sends the SIGINT
to the process, and like gdbserver, assumes the inferior's
PID is the process group id.

Thanks,
Pedro Alves

Re: [PATCH] [GDBServer] Send SIGINT using process group ID

[Jim Chen]

The use case was attaching, like you mentioned, on Android. And I just 
found PR/18945 [1], which describes the problem. I now see that my patch 
is not a good solution either because on Android, the pgid is the zygote 
process, and all running apps on the system belong to that group.

Seems like the best solution is to handle attaching separately? Or maybe 
send SIGINT to the process first, and if that fails, send it to the 
process group, in order to address the original bug of a dead main 
thread when pausing?

Thanks,
Jim

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=18945

On 5/18/2016 8:10 AM, Pedro Alves wrote:
> On 05/11/2016 10:51 PM, Jim Chen wrote:
>> Hi,
>>
>> linux_request_interrupt is supposed to send SIGINT to the process group,
>> but it passes the process ID to kill() instead of the process group ID,
>> which may not be the same as the process ID.
>> The patch calls getpgid
>> first to get the process group ID.
>>
>> Patch tested on arm-linux.
>
> Can you expand on the use case you see this happening on, please?
> I can imagine some, but I'd like to hear it from you.
>
> Some have expressed desire to _not_ send the SIGINT to the whole
> process group, which may make sense when you're attached to a
> process rather than having started it.  IIRC, there's a bug filed in
> bugzilla about this.
>
> Looking at the code, not-sending-to-process-group-when-attached
> is what native GNU/Linux does too (inflow.c:pass_signal).
>
> Seems like "c&" -> "interrupt" doesn't consider "attach" either,
> as inf-ptrace.c:inf_ptrace_interrupt sends the SIGINT
> to the process, and like gdbserver, assumes the inferior's
> PID is the process group id.
>
> Thanks,
> Pedro Alves
>