[PATCH v1] [gdb/python] Bploc should try to return full path

[Simon Farre]

Compilers often emit relative paths in the line number program,
relative to the build directory for that compilation unit (if it's
DWARF>=4 I think).

Therefore use symtab->fullname() when not null as this seemingly
has attempted path normalization for the symtab and only
fall back on symtab->filename which will never be null if that fails.

This has a much better UX. Applications may choose to expose
this name as a clickable link to some file, at which point
a non-normalized and non-absolute path would lead nowhere.

When I wrote this feature the first time, I don't think this
relative-to-cu-scheme was as prevalent in the output of gcc/clang
for DWARF.
---
 gdb/python/py-breakpoint.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gdb/python/py-breakpoint.c b/gdb/python/py-breakpoint.c
index 75f50e1f423..37152d32c0b 100644
--- a/gdb/python/py-breakpoint.c
+++ b/gdb/python/py-breakpoint.c
@@ -1643,9 +1643,10 @@ bplocpy_get_source_location (PyObject *py_self, void *closure)
       gdbpy_ref<> tup (PyTuple_New (2));
       if (tup == nullptr)
 	return nullptr;
-      /* symtab->filename is never NULL. */
-      gdbpy_ref<> filename
-	= host_string_to_python_string (self->bp_loc->symtab->filename);
+      const char *full = self->bp_loc->symtab->fullname ();
+      gdbpy_ref<> filename = full != nullptr
+        ? host_string_to_python_string (full)
+        : host_string_to_python_string (self->bp_loc->symtab->filename);
       if (filename == nullptr)
 	return nullptr;
       auto line = gdb_py_object_from_ulongest (self->bp_loc->line_number);
-- 
2.47.1