[Bug tdep/17903] New: gdb cannot determine executable when attaching to processes on Solaris

[ro at TechFak dot Uni-Bielefeld.DE]

https://sourceware.org/bugzilla/show_bug.cgi?id=17903

Bug ID: 17903
Summary: gdb cannot determine executable when attaching to
processes on Solaris
Product: gdb
Version: 7.8
Status: NEW
Severity: normal
Priority: P2
Component: tdep
Assignee: unassigned at sourceware dot org
Reporter: ro at TechFak dot Uni-Bielefeld.DE
Host: *-*-solaris2.*

When attaching to a running process, gdb cannot determine the executable on
Solaris, thus has no symbol information. Linux is different here:

***@fozzie 148 > gdb
GNU gdb (GDB) 7.8
[...]
This GDB was configured as "x86_64-unknown-linux-gnu".
[...]
(gdb) attach 2092
Attaching to process 2092
Reading symbols from /usr/local/bin/bash...done.
[...]
0x0000003231abc2fc in waitpid () from /lib64/libc.so.6
(gdb) where
#0 0x0000003231abc2fc in waitpid () from /lib64/libc.so.6
#1 0x000000000043d23b in waitchld (wpid=<optimized out>, block=1)
at jobs.c:3093
#2 0x000000000043ec3b in wait_for (pid=26784) at jobs.c:2450
#3 0x0000000000430470 in execute_command_internal (command=0x2519600,
asynchronous=0, pipe_in=-1, pipe_out=<optimized out>,
fds_to_close=<optimized out>) at execute_cmd.c:775
#4 0x000000000042deef in execute_command (command=0x2519600)
at execute_cmd.c:382
#5 0x000000000041db38 in reader_loop () at eval.c:152
#6 0x000000000041d60b in main (argc=<optimized out>, argv=0x7fffddd4e878,
env=0x7fffddd4e888) at shell.c:749

On Solaris, you get far less information instead:

***@lokon 2721 > gdb
GNU gdb (GDB) 7.8
[...]
This GDB was configured as "i386-pc-solaris2.10".
[...]
(gdb) attach 2032
Attaching to process 2032
[New process 2032]
Retry #1:
Retry #2:
Retry #3:
Retry #4:
0xfe6cbc55 in ?? ()

This happens because Solaris currently doesn't implement the
to_pid_to_exec_file,
although that's certainly feasible:

* On Solaris 10 and beyond, there's /proc/<pid>/path/a.out, the exact
equivalent
to Linux' /proc/<pid>/exe, it seems.

* Before, there's at least a heuristic available: the execname can be accessed
via the AT_SUN_EXECNAME auxv entry, but that can be a relative path. One
could combine it with /proc/<pid>/cwd, but that's unreliable since the
process
could have run chdir between exec and attach.

Rainer

[phantall at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17903

phantall at gmail dot com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |phantall at gmail dot com
Version|7.8 |7.10

--- Comment #1 from phantall at gmail dot com ---
This is still an issue on Solaris 10.

[phantall at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17903

--- Comment #2 from phantall at gmail dot com ---
(In reply to phantall from comment #1)

Post by phantall at gmail dot com
This is still an issue on Solaris 10.

I left out some details:

* sparc
* gdb 7.10

[phantall at gmail dot com]

This post might be inappropriate. Click to display it.

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17903

Pedro Alves <palves at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com

--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
This is probably not sparc-specific, so you should do it in gdb/procfs.c, the
main Solaris support file.

Don't be scared about the IRIX, AIX, etc. comments. That's all stale, the file
is only used for Solaris nowadays. It could use a general cleanup...

Please take a look at:

http://sourceware.org/gdb/wiki/ContributionChecklist

[phantall at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17903

--- Comment #5 from phantall at gmail dot com ---
Created attachment 8851
--> https://sourceware.org/bugzilla/attachment.cgi?id=8851&action=edit
unix procfs to_pid_to_exec_file implementation

This implementation is generic enough that it could be used for all procfs
platforms that adhere to the possible paths I used.

Some notes on this:

* I'm not terribly fond of the idea of returning a static like this, but the
code using it (exec_file_locate_attach) is written under the assumption it does
not take ownership of that memory.
* This could be done with no loop:
** ... using #if, but that makes the code uglier/less readable, and I see no
terribly compelling argument against the loop
** On each platform add a format string to the target_ops struct (would require
adding a new member to target_ops).
** Only use the string that works on Solaris and forget about making it more
general purpose

[phantall at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17903

--- Comment #6 from phantall at gmail dot com ---
I don't have DejaGNU installed on any of the machines I have access to, and
getting it approved/installed would take months.

This resolves the problem of attaching on Solaris 10/sparc. The code isn't
built for x86/Linux, I had no need to test it there.

In the tests I've ran this function executes only if the path to the current
target is empty:

* path to an executable not specified in arguments
* "file" / "exec-file" haven't been used
* "file" or "exec-file" were called with an empty string

[phantall at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17903

--- Comment #7 from phantall at gmail dot com ---
Comment on attachment 8851
--> https://sourceware.org/bugzilla/attachment.cgi?id=8851
unix procfs to_pid_to_exec_file implementation

diff --git a/gdb/procfs.c b/gdb/procfs.c
index 7b7ff45..a663223 100644
--- a/gdb/procfs.c
+++ b/gdb/procfs.c
@@ -51,6 +51,7 @@
#include "auxv.h"
#include "procfs.h"
#include "observer.h"
+#include "ansidecl.h"
/* This module provides the interface between GDB and the
/proc file system, which is used on many versions of Unix
@@ -118,6 +119,7 @@ static void procfs_fetch_registers (struct target_ops *,
struct regcache *, int);
static void procfs_store_registers (struct target_ops *,
struct regcache *, int);
+static char* procfs_child_pid_to_exec_file( struct target_ops*, int );
static void procfs_pass_signals (struct target_ops *self,
int, unsigned char *);
static void procfs_kill_inferior (struct target_ops *ops);
@@ -192,6 +194,7 @@procfs_target (void)
t->to_resume = procfs_resume;
t->to_fetch_registers = procfs_fetch_registers;
t->to_store_registers = procfs_store_registers;
+ t->to_pid_to_exec_file = procfs_child_pid_to_exec_file;
t->to_xfer_partial = procfs_xfer_partial;
t->to_pass_signals = procfs_pass_signals;
t->to_files_info = procfs_files_info;
@@ -3301,6 +3304,41 @@ procfs_store_registers (struct target_ops *ops,
}
}
+/* "self" may not exist on some platforms,
+ * otherwise that would be preferable to
+ * a format string. */
+static const char *proc_path_lookup[] = {
+ "/proc/%u/path/a.out" // Most UNIXes with procfs (Solaris)
+, "/proc/%u/file" // BSD
+, "/proc/%u/exe" // Linux, Windows, NetBSD
+, "/proc/%u/a.out" // No idea, I've only seen references to it
+};
+
+/* Get a fully qualified path to the debugged process */
+static char* procfs_child_pid_to_exec_file( struct target_ops *ARG_UNUSED(self), int pid ) {
+ static char buf[PATH_MAX] = {0};
+ char name[PATH_MAX] = {0};
+ ssize_t sz = -1;
+ size_t ii = 0;
+
+ pid = pid >= 0 ? pid : -pid;
+
+ for( ii = 0; ii < sizeof(proc_path_lookup)/sizeof(proc_path_lookup[0]); ++ii ) {
+ xsnprintf( name, sizeof(name), proc_path_lookup[ii], (unsigned int)pid );
+ sz = readlink( name, buf, sizeof( name ) );
+
+ if( 0 < sz ) {
+ buf[sz] = '\0';
+ return buf;
+ }
+ }
+
+ /* This is the default behavior as defined in target.h
+ * and implemented in inf_child_pid_to_exec_file() */
+ return NULL;
+}
+

[ro at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17903

Rainer Orth <ro at gcc dot gnu.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
URL| |https://sourceware.org/ml/g
| |db-patches/2018-09/msg00682
| |.html

--- Comment #8 from Rainer Orth <ro at gcc dot gnu.org> ---
Patch submitted.

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17903

--- Comment #9 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Rainer Orth <***@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4206c05ea1542c413a4a361c29cbbd206861946c

commit 4206c05ea1542c413a4a361c29cbbd206861946c
Author: Rainer Orth <***@CeBiTec.Uni-Bielefeld.DE>
Date: Thu Sep 20 11:23:27 2018 +0200

Provide pid_to_exec_file on Solaris (PR tdep/17903)

While looking through gdb.log, I found that two tests FAIL like this:

warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x00400dc4 in ?? ()
(gdb) FAIL: gdb.base/attach.exp: attach2, with no file

The other is gdb.base/quit-live.exp. I've implemented the following
patch that fixes both failures, only then detecting that I'd previously
reported the issue as PR tdep/17903.

Tested on amd64-pc-solaris2.10 and amd64-pc-solaris2.11.

PR tdep/17903
* procfs.c (procfs_target): Declare pid_to_exec_file.
(procfs_target::pid_to_exec_file): New.

[ro at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17903

Rainer Orth <ro at gcc dot gnu.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
URL|https://sourceware.org/ml/g |https://sourceware.org/ml/g
|db-patches/2018-09/msg00682 |db-patches/2018-09/msg00727
|.html |.html
Resolution|--- |FIXED
Assignee|unassigned at sourceware dot org |ro at gcc dot gnu.org
Target Milestone|--- |8.3

--- Comment #10 from Rainer Orth <ro at gcc dot gnu.org> ---
Fixed for 8.3.