From a10de6046fbd50e99742af428a815dcd94e2fba8 Mon Sep 17 00:00:00 2001 From: Gary Benson Date: Fri, 17 Apr 2015 09:47:30 +0100 Subject: Introduce exec_file_locate_attach This commit adds a new function, exec_file_locate_attach, which works like exec_file_attach except that, instead of a filename argument, it takes an integer process ID and attempts to determine the executable filename from that. gdb/ChangeLog: * gdbcore.h (exec_file_locate_attach): New declaration. * exec.c (exec_file_locate_attach): New function, factored out from... * infcmd.c (attach_command_post_wait): ...here. --- gdb/exec.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'gdb/exec.c') diff --git a/gdb/exec.c b/gdb/exec.c index 44c8480..9d4ad90 100644 --- a/gdb/exec.c +++ b/gdb/exec.c @@ -134,6 +134,37 @@ exec_file_clear (int from_tty) printf_unfiltered (_("No executable file now.\n")); } +/* See gdbcore.h. */ + +void +exec_file_locate_attach (int pid, int from_tty) +{ + char *exec_file, *full_exec_path = NULL; + + /* Do nothing if we already have an executable filename. */ + exec_file = (char *) get_exec_file (0); + if (exec_file != NULL) + return; + + /* Try to determine a filename from the process itself. */ + exec_file = target_pid_to_exec_file (pid); + if (exec_file == NULL) + return; + + /* It's possible we don't have a full path, but rather just a + filename. Some targets, such as HP-UX, don't provide the + full path, sigh. + + Attempt to qualify the filename against the source path. + (If that fails, we'll just fall back on the original + filename. Not much more we can do...) */ + if (!source_full_path_of (exec_file, &full_exec_path)) + full_exec_path = xstrdup (exec_file); + + exec_file_attach (full_exec_path, from_tty); + symbol_file_add_main (full_exec_path, from_tty); +} + /* Set FILENAME as the new exec file. This function is intended to be behave essentially the same -- cgit v1.1