This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] cleanup dwo files left in testsuite source tree


Hi.

Testing gdb.base/fullpath-expand.exp with -gsplit-dwarf leaves
a few files behind in the source tree.

bash$ git status
[...]
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	testsuite/fullpath-expand-func.dwo
#	testsuite/fullpath-expand.dwo

This is because the test first cd's to the source tree and
runs the compilation there, and gcc creates the dwo files there.

This patch cleans up the files after the test.
I'm not intending to check it in at present since I'm not sure
it's the best solution, and I doubt many test with fission and
thus don't care.
I think(!) a better solution would be to have a way to tell gcc
where to put dwo files, and maybe use a different default for the
"gcc -gsplit-dwarf foo.c bar.c -o /tmp/baz" case.
Things get a bit complicated in that DW_AT_GNU_dwo_name is generally
relative to DW_AT_comp_dir which is $srcdir.  One could record an
absolute path but that complicates providing gdb with alternative
directories in which to find dwo files (with debug-file-directory, which
is essentially a list of directories to try instead of DW_AT_comp_dir).
One could create a new DWARF attribute to use instead of
DW_AT_comp_dir for this purpose.  DW_AT_GNU_dwo_dir?
[If present, use that to find DW_AT_GNU_dwo_name.
Otherwise use DW_AT_comp_dir.]

Still, if I do "gcc foo.c bar.c -o /tmp/baz" I can be assured
gcc won't try to create any files in the current directory
(e.g. I could be compiling in a readonly source tree).
-gsplit-dwarf doesn't follow this convention.
IWBN I think, at least in this particular example, if gcc put the dwo files
in the same directory as baz.

Anyways, for reference sake, here's the patch.

diff --git a/gdb/testsuite/gdb.base/fullpath-expand.exp b/gdb/testsuite/gdb.base/fullpath-expand.exp
index 949f3fc..29be0b0 100644
--- a/gdb/testsuite/gdb.base/fullpath-expand.exp
+++ b/gdb/testsuite/gdb.base/fullpath-expand.exp
@@ -42,3 +42,10 @@ gdb_test "rbreak $realsrcfile2:func" "^rbreak \[^\r\n\]*:func\r\nBreakpoint 1 at
 # Verify the compilation pathnames are as expected:
 gdb_test "list func" "\tfunc \\(void\\)\r\n.*"
 gdb_test "info source" "^info source\r\nCurrent source file is [string_to_regexp ${subdir}/${srcfile2}]\r\nCompilation directory is /.*"
+
+# Fission leaves dwo files in the source tree.
+# Clean them up.  We can't clean them up sooner because gdb needs the
+# debug info contained in them.
+foreach file [list ${srcfile} ${srcfile2}] {
+    remote_file host delete ${srcdir}/[file rootname ${file}].dwo
+}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]