Re: [PATCH][PR gdb/17903] Implement to_pid_to_exec_file for solaris

[Pedro Alves <palves at redhat dot com>]

Hi Brian,

Thanks for the patch.

On 12/16/2015 09:47 PM, Brian Vandenberg wrote:
> This patch is to address an issue in Solaris,
> bug 17903.
> 
> When attaching to a process by PID the current
> implementation in gdb/procfs.c leaves
> "to_pid_to_exec_file" at the default -- a stub
> function that returns NULL.
> 
> This causes symbols not to load when attaching,
> forcing the user to either attach by specifying
> the path on the command line or inside gdb.
> After specifying the file inside gdb it's also
> necessary to manually load symbolic information.
> 
> The proposed change resembles the implementation
> in gdb/linux-nat.c, but is generic enough that it
> could work on most platforms supporting procfs
> and could potentially be used as a replacement
> for the current default.
> 
> If you only care about fixing this in Solaris 10+,
> the loop could be done away with and readlink
> could just read from "/proc/self/path/a.out",
> allowing you to get rid of the xsnprintf call
> as well.

Yes, please simplify the patch.  There's no point in
trying to open files we know don't exist on the OS.

Why are you handling negative PIDs?  How do we get here with such a PID?

BTW, the patch should follow the GNU coding standards formatting.

> 
> I don't have DejaGNU installed on my development
> machines at work and I don't have one [that functions]
> at home, so I was unable to run the test suite (otherwise
> I would have).

Note that DejaGNU is very easy to build -- just configure/make.
I don't think is has any usually-unavailable dependency, other
than expect, and that one you may already have.

But did you try setting up a Solaris VM?  Oracle provides pre-built
Solaris VMs for VirtualBox available, IIRC, so shouldn't be hard.

> 
> Lastly: I made these changes on a machine that
> doesn't have network access.  I had to hand-type
> the following diff.  My apologies if there are
> typos; I did my best.  Obviously I won't be able to
> push this myself.
> 

Ouch.  :-/

Thanks,
Pedro Alves