[Bug gdb/24445] New: dwz multifile index not written to index cache

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] New: dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

            Bug ID: 24445
           Summary: dwz multifile index not written to index cache
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Spin-off of PR24438 comment 2. ]

Consider the debug script debug.sh:
...
$ cat debug.sh
#!/bin/sh

orig=true
#orig=false
if $orig; then
    exec=build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache.orig
    file $exec
else
    exec=build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
    file $exec
    dwz=build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache.dwz
    file $dwz
fi

rm -f ~/.cache/gdb/*

echo "One:"

./build/gdb/gdb \
    -iex "set index-cache on" \
    -iex "set debug index-cache" \
    $exec \
    -ex "show index-cache stats" \
    -batch

ls -la ~/.cache/gdb

echo "Two:"

./build/gdb/gdb \
    -iex "set index-cache on" \
    -iex "set debug index-cache" \
    $exec \
    -ex "show index-cache stats" \
    -batch
...

With orig == true, I run the script on the original executable, with orig ==
false, I run it on the dwz -m modified version.

With orig == true, I get:
...
build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache.orig: ELF 64-bit
LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter
/lib64/l, for GNU/Linux 3.2.0,
BuildID[sha1]=7481d8a114be967ca8c6581017a68e9586c265c7, with debug_info, not
stripped
One:
index cache: trying to read
/home/vries/.cache/gdb/7481d8a114be967ca8c6581017a68e9586c265c7.gdb-index
index cache: couldn't read
/home/vries/.cache/gdb/7481d8a114be967ca8c6581017a68e9586c265c7.gdb-index:
open: Bestand of map bestaat niet.
index cache: writing index cache for objfile
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache.orig
  Cache hits (this session): 0
Cache misses (this session): 1
totaal 16
drwx------  2 vries users   64 11 apr 14:14 .
drwxr-xr-x 40 vries users 4096 10 apr 18:10 ..
-rw-------  1 vries users 8681 11 apr 14:14
7481d8a114be967ca8c6581017a68e9586c265c7.gdb-index
Two:
index cache: trying to read
/home/vries/.cache/gdb/7481d8a114be967ca8c6581017a68e9586c265c7.gdb-index
  Cache hits (this session): 1
Cache misses (this session): 0
...

With orig == false, I get:
...
build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache: ELF 64-bit LSB
executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l,
for GNU/Linux 3.2.0, BuildID[sha1]=7481d8a114be967ca8c6581017a68e9586c265c7,
with debug_info, not stripped
build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache.dwz: ELF 64-bit
LSB relocatable, x86-64, version 1 (SYSV),
BuildID[sha1]=d33c79ccf37ba8e54bdd0f9e02b631a1595f4926, stripped
One:
index cache: trying to read
/home/vries/.cache/gdb/7481d8a114be967ca8c6581017a68e9586c265c7.gdb-index
index cache: couldn't read
/home/vries/.cache/gdb/7481d8a114be967ca8c6581017a68e9586c265c7.gdb-index:
open: Bestand of map bestaat niet.
index cache: writing index cache for objfile
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
  Cache hits (this session): 0
Cache misses (this session): 1
totaal 16
drwx------  2 vries users   64 11 apr 14:15 .
drwxr-xr-x 40 vries users 4096 10 apr 18:10 ..
-rw-------  1 vries users 8681 11 apr 14:15
7481d8a114be967ca8c6581017a68e9586c265c7.gdb-index
Two:
index cache: trying to read
/home/vries/.cache/gdb/7481d8a114be967ca8c6581017a68e9586c265c7.gdb-index
index cache: trying to read
/home/vries/.cache/gdb/d33c79ccf37ba8e54bdd0f9e02b631a1595f4926.gdb-index
index cache: couldn't read
/home/vries/.cache/gdb/d33c79ccf37ba8e54bdd0f9e02b631a1595f4926.gdb-index:
open: Bestand of map bestaat niet.
index cache: writing index cache for objfile
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache
  Cache hits (this session): 0
Cache misses (this session): 1
...

So, AFAIU:
- when loading the original executable, gdb:
  - cannot find a cached index in the clean directory, then
  - saves one, and then
  - can find the saved one
- when loading the dwz-m-ed executable, gdb:
  - cannot find a cached index in the clean directory, then
  - saves one for the executable but not for the .gnu_debugaltlink file,
    and then
  - cannot load the saved one because it requires the cached index for the
    .gnu_debugaltlink file.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
Thanks for the report, I managed to reproduce.

I am not too familiar with dwz files, so I don't know what the proper solution
is.

- Can dwz files have indices?  If so, should we save it as well?
- Or does the index of the top-level/importer DWARF file contain everything,
and therefore we should not be looking for an index for the DWZ file?

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #1)
> Thanks for the report, I managed to reproduce.
>
> I am not too familiar with dwz files, so I don't know what the proper
> solution is.
>
> - Can dwz files have indices?

Yes:
...
$ make hello
$ gdb-add-index hello
$ cp hello 1; cp 1 2; rm -f 3; ./dwz -m 3 1 2
$ readelf -S 3 | grep -A1 gdb_index
 [ 6] .gdb_index        PROGBITS         0000000000000000  00000c06
       0000000000000078  0000000000000000           0     0     1
...

>  If so, should we save it as well?
> - Or does the index of the top-level/importer DWARF file contain everything,
> and therefore we should not be looking for an index for the DWZ file?

I wondered about the same, but I'm not sure yet how to find that out.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> (In reply to Simon Marchi from comment #1)
> >  If so, should we save it as well?
> > - Or does the index of the top-level/importer DWARF file contain everything,
> > and therefore we should not be looking for an index for the DWZ file?
>
> I wondered about the same, but I'm not sure yet how to find that out.

I've done a debug session with an executable with .gnu_debugaltlink file, and
managed to trigger this clause:
...
      /* CU of a shared file from 'dwz -m' may be unused by this main file.    
         It may be referenced from a local scope but in such case it does not  
         need to be present in .gdb_index.  */
      if (psymtab == NULL)
        continue;

...
in write_gdbindex, and printing the *per_cu at that point got me an offset and
size that matched a CU in the .gnu_debugaltlink file.

So, I'm starting to lean towards the idea that what is necessary for the gdb
index for the .gnu_debugaltlink file portion, is already written out into the
main gdb index file.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
I've looked into this a bit more in detail.

I.

Both cc-with-tweaks.sh and find-debuginfo.sh first add an index, then do dwz.


II.

If we first add an index to a hello world with debug info, and then do dwz -m,
the multifile has an index:
...
$ cp hello 1
$ gdb-add-index 1
$ cp 1 2
$ dwz -m 3 1 2
$ for f in 1 2 3; do echo -n "$f: "; readelf -S $f | grep -c .gdb_index; done
1: 1
2: 1
3: 1
...

and readelf -w 1 gives us:
...
Contents of the .gdb_index section (loaded from 1):

Version 8

CU table:
[  0] 0x0 - 0x1e
[  1] 0x1f - 0x4c
[  2] 0x4d - 0x86
[  3] 0x87 - 0xa8
[  4] 0xa9 - 0x2b8
[  5] 0x2b9 - 0x3c3
[  6] 0x3c4 - 0x3e5

TU table:

Address table:
00000000004003f0 0000000000400402 3
0000000000400402 0000000000400407 6
0000000000400430 000000000040045b 1
0000000000400507 000000000040051c 4
0000000000400520 0000000000400592 5
0000000000400594 0000000000400598 3
0000000000400598 000000000040059d 6

Symbol table:
[ 40] __libc_csu_fini: 5 [global, function]
[ 52] short unsigned int: 2 [static, type]
[ 68] unsigned char: 2 [static, type]
[ 94] _IO_stdin_used: 2 [global, variable]
[114] size_t: 4 [static, type]
[135] __off_t: 4 [static, type]
[343] long unsigned int: 2 [static, type]
[442] short int: 2 [static, type]
[452] long double: 5 [static, type]
[454] long long int: 5 [static, type]
[489] main: 4 [global, function]
[518] char: 2 [static, type]
[550] _IO_lock_t: 4 [static, type]
[592] _IO_marker: 4 [static, type]
[689] signed char: 2 [static, type]
[718] _IO_FILE: 4 [static, type]
[732] unsigned int: 2 [static, type]
[754] int: 2 [static, type]
[802] __libc_csu_init: 5 [global, function]
[825] __off64_t: 4 [static, type]
[955] long int: 2 [static, type]
...

as well as:
...
Contents of the .gdb_index section (loaded from 3):

Version 8

CU table:
[  0] 0x0 - 0x37
[  1] 0x38 - 0x5d
[  2] 0x5e - 0x2a9
[  3] 0x2aa - 0x32f
[  4] 0x330 - 0x360

TU table:

Address table:

Symbol table:
...

Note that the .gdb_index section in 3 is used for both 1 and 3.


III.

If we first do dwz -m on a hello world with debug info, and then add an index,
the multifile has no index:
...
$ cp hello 1
$ cp 1 2
$ dwz -m 3 1 2
$ gdb-add-index 1
$ for f in 1 2 3; do echo -n "$f: "; readelf -S $f | grep -c .gdb_index; done
1: 1
2: 0
3: 0
...

and readelf -w 1 gives us:
...
Contents of the .gdb_index section (loaded from 1):

Version 8

CU table:
[  0] 0x0 - 0x1e
[  1] 0x1f - 0x4c
[  2] 0x4d - 0x86
[  3] 0x87 - 0xa8
[  4] 0xa9 - 0x2b8
[  5] 0x2b9 - 0x3c3
[  6] 0x3c4 - 0x3e5
[  7] 0x0 - 0x37
[  8] 0x38 - 0x5d
[  9] 0x5e - 0x2a9
[ 10] 0x330 - 0x360

TU table:

Address table:
00000000004003f0 0000000000400402 3
0000000000400402 0000000000400407 6
0000000000400430 000000000040045b 1
0000000000400507 000000000040051c 4
0000000000400520 0000000000400592 5
0000000000400594 0000000000400598 3
0000000000400598 000000000040059d 6

Symbol table:
[ 40] __libc_csu_fini: 5 [global, function]
[ 52] short unsigned int: 2 [static, type]
[ 68] unsigned char: 2 [static, type]
[ 94] _IO_stdin_used: 2 [global, variable]
[114] size_t: 4 [static, type]
[135] __off_t: 4 [static, type]
[343] long unsigned int: 2 [static, type]
[442] short int: 2 [static, type]
[489] main: 4 [global, function]
[518] char: 2 [static, type]
[550] _IO_lock_t: 4 [static, type]
[592] _IO_marker: 4 [static, type]
[689] signed char: 2 [static, type]
[718] _IO_FILE: 4 [static, type]
[732] unsigned int: 2 [static, type]
[754] int: 2 [static, type]
[802] __libc_csu_init: 5 [global, function]
[825] __off64_t: 4 [static, type]
[955] long int: 2 [static, type]
...

The overlapping CUs look wrong to me:
...
CU table:
[  0] 0x0 - 0x1e
[  1] 0x1f - 0x4c
[  2] 0x4d - 0x86
[  3] 0x87 - 0xa8
[  4] 0xa9 - 0x2b8
[  5] 0x2b9 - 0x3c3
[  6] 0x3c4 - 0x3e5
[  7] 0x0 - 0x37
[  8] 0x38 - 0x5d
[  9] 0x5e - 0x2a9
[ 10] 0x330 - 0x360
...

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #5 from Simon Marchi <simark at simark dot ca> ---

> The overlapping CUs look wrong to me:
> ...
> CU table:
> [  0] 0x0 - 0x1e
> [  1] 0x1f - 0x4c
> [  2] 0x4d - 0x86
> [  3] 0x87 - 0xa8
> [  4] 0xa9 - 0x2b8
> [  5] 0x2b9 - 0x3c3
> [  6] 0x3c4 - 0x3e5
> [  7] 0x0 - 0x37
> [  8] 0x38 - 0x5d
> [  9] 0x5e - 0x2a9
> [ 10] 0x330 - 0x360
> ...

Agreed, I did some similar experiment and arrived to the same conclusion.  If
you inspect your files 1 and 3 (readelf --debug-dump=info), I think we'll see
that CU indices 0-6 above represent the CUs in file 1's debug info, while 7-10
represents CUs in file 3's debug info.

When we try to load file 1 in GDB, the index is not used for the same reason as
why it wasn't used with the index cache.  dwarf2_read_gdb_index notices that
there is an external (dwz) file, so tries to read the index from it.  Since it
doesn't have one, the index isn't used.  By the way, this code
(dwarf2_read_gdb_index) suggests that that it is correct (and even required)
for the external dwz file to have an index if the main file has an index.  That
would answer my previous interrogations.

So this is a deeper issue in "save gdb-index"/gdb-add-index, which doesn't do
the right thing when a dwz file is present:

- The index created for the main executable should not include things from the
external dwz file, since the dwz file will have its own index with these
things.
- When running gdb-add-index on a file that refers to an external dwz file, we
should create an index for the dwz file.  Otherwise, the index created for the
main file is useless, as GDB will not use it if the dwz file doesn't also have
an index.

If two main programs (a and b) refer to the same dwz file (c.dwz), running
gdb-add-index on a would then modify both a and c.dwz.  Running gdb-add-index
on b after this would just modify b, since c.dwz already has an index.  Whether
you run gdb-add-index on a or b first should result in the same index inserted
in c.dwz.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #6 from Simon Marchi <simark at simark dot ca> ---
I tackled this a little bit this weekend, here's a crude, very lightly tested
patch.  It makes GDB:

- Not put the CUs from the DWZ file in the index for the main object file.
- Create an index for the DWZ file, with only the list of CUs contained in the
DWZ file.

With this patch, if I run dwz then generate some indices with GDB, I get the
same index contents as if I generate (and insert) the index with GDB then run
dwz.

The only difference is that the symbol hash table of the dwz file's index, in
the  "index then dwz" case, is an empty hash table of size two.  In the case of
"dwz then index" (what my patch produces), the symbol hash table is of size 0.
If that's not valid, we can always produce an empty hash table of size
non-zero, just like the dwz tool does.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #7 from Simon Marchi <simark at simark dot ca> ---
Created attachment 11758
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11758&action=edit
Patch that generates indices for dwz files

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
I've tested the patch with cc-with-dwz-m.exp, and found no regressions, but
still have:
...
FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: expected file is there
FAIL: gdb.dwarf2/gdb-index.exp: save gdb-index for file gdb-index
FAIL: gdb.dwarf2/gdb-index.exp: index used
FAIL: gdb.dwarf2/gdb-index.exp: index used after symbol reloading
...

I've looked at:
...
FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: expected file is there
...
and that's a test-case error, fixed by:
...
diff --git a/gdb/testsuite/gdb.base/index-cache.exp
b/gdb/testsuite/gdb.base/index-cache.exp
index 4e583abf01..011d3bf0f4 100644
--- a/gdb/testsuite/gdb.base/index-cache.exp
+++ b/gdb/testsuite/gdb.base/index-cache.exp
@@ -48,7 +48,7 @@ proc ls_host { dir } {
        }
     }

-    return "0 $filtered"
+    return [list 0 "$filtered"]
 }

 # Execute "show index-cache stats" and verify the output against expected
...

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #8)
> FAIL: gdb.dwarf2/gdb-index.exp: save gdb-index for file gdb-index

This is fixed by:
...
diff --git a/gdb/dwarf-index-cache.c b/gdb/dwarf-index-cache.c
index d553eb0a07..3f350593a8 100644
--- a/gdb/dwarf-index-cache.c
+++ b/gdb/dwarf-index-cache.c
@@ -33,7 +33,7 @@
 #include <stdlib.h>

 /* When set to 1, show debug messages about the index cache.  */
-static int debug_index_cache = 0;
+int debug_index_cache = 0;

 /* The index cache directory, used for "set/show index-cache directory".  */
 static char *index_cache_directory = NULL;
diff --git a/gdb/dwarf-index-common.h b/gdb/dwarf-index-common.h
index 2035dce0c2..a469ce84e6 100644
--- a/gdb/dwarf-index-common.h
+++ b/gdb/dwarf-index-common.h
@@ -65,4 +65,6 @@ hashval_t mapped_index_string_hash (int index_version, const
void *p);

 uint32_t dwarf5_djb_hash (const char *str_);

+extern int debug_index_cache;
+
 #endif /* DWARF_INDEX_COMMON_H */
diff --git a/gdb/dwarf-index-write.c b/gdb/dwarf-index-write.c
index 67fc886680..00af8e971a 100644
--- a/gdb/dwarf-index-write.c
+++ b/gdb/dwarf-index-write.c
@@ -1593,8 +1593,11 @@ write_psymtabs_to_index (struct dwarf2_per_objfile
*dwarf2_per_objfile,
       || !objfile->partial_symtabs->psymtabs_addrmap)
     return;

-  printf("basename = %s\n", basename);
-  printf("dwz_basename = %s\n", dwz_basename);
+  if (debug_index_cache)
+    {
+      printf_unfiltered ("basename = %s\n", basename);
+      printf_unfiltered ("dwz_basename = %s\n", dwz_basename);
+    }

   struct stat st;
   if (stat (objfile_name (objfile), &st) < 0)
...

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #10 from Simon Marchi <simark at simark dot ca> ---
Haha, those weren't meant to be there in the final patch :).  But it's true we
can leave them as debug traces if they are deemed useful.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #8)

> and that's a test-case error, fixed by:
> ...
> diff --git a/gdb/testsuite/gdb.base/index-cache.exp
> b/gdb/testsuite/gdb.base/index-cache.exp
> index 4e583abf01..011d3bf0f4 100644
> --- a/gdb/testsuite/gdb.base/index-cache.exp
> +++ b/gdb/testsuite/gdb.base/index-cache.exp
> @@ -48,7 +48,7 @@ proc ls_host { dir } {
>         }
>      }
>  
> -    return "0 $filtered"
> +    return [list 0 "$filtered"]
>  }
>  
>  # Execute "show index-cache stats" and verify the output against expected
> ...

Fixed at https://sourceware.org/ml/gdb-patches/2019-05/msg00183.html .

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch submitted: https://sourceware.org/ml/gdb-patches/2019-05/msg00188.html

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #12)
> Patch submitted: https://sourceware.org/ml/gdb-patches/2019-05/msg00188.html

Corresponding gdb/contrib/gdb-add-index.sh update RFC-ed:
https://sourceware.org/ml/gdb-patches/2019-05/msg00191.html .

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #14 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <[hidden email]>:

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

commit c4973306879b6079bdfc997474a2cbbd89f49bd2
Author: Simon Marchi <[hidden email]>
Date:   Sun Jun 16 10:13:56 2019 -0400

    Write index for dwz -m file

    PR 24445 ("dwz multifile index not written to index cache") exposed the
    fact that we are not doing things right when we generate an index for an
    object file that has is linked to a dwz file.  The same happens whether
    the index is generated with the intent of populating the index cache or
    using the save gdb-index command.

    The problem can be observed when running these tests with the
    cc-with-dwz-m board:

        FAIL: gdb.base/index-cache.exp: test_cache_enabled_hit: check
index-cache stats
        FAIL: gdb.dwarf2/gdb-index.exp: index used
        FAIL: gdb.dwarf2/gdb-index.exp: index used after symbol reloading

    When generating the index for such file and inspecting the CU list of the
    resulting index (with readelf --debug-dump=gdb_index), we can see something
    like:

        CU table:
        [  0] 0x0 - 0xb9
        [  1] 0x0 - 0x44

    This is supposed to be a sorted list of the ranges of all CUs in the
    file this index represents, so already having some overlap is a red
    flag.  It turns out that we save the ranges of CUs coming from both the
    main file and the dwz file in the same index.

    After digging a little bit, it became quite obvious that the index in
    the main file should only list the CUs present in the main file, and a
    separate index should be generated for the dwz file, listing the CUs
    present in that file.

    First, that's what happens if you run dwz on a file that already has a
    GDB index embedded.  Second, dwarf2read.c has code to read an index from
    a dwz file.  The index in the dwz file is actually required to be
    present, if the main file has an index.

    So this patch changes write_psymtabs_to_index to generate an index for
    the dwz file, if present.  That index only contains a CU list, just like
    what the dwz tool does when processing a file that already contains an
    index.

    Some notes about the implementation:

    - The file management (creating a temp file, make sure it's
      close/removed on error - in the right order) is a bit heavy in
      write_psymtabs_to_index, and I needed to add a third file.  I factored
      this pattern in a separate class, index_wip_file.
    - It became a bit tedious to keep the call to assert_file_size in
      write_psymtabs_to_index, write_gdbindex would have had to return two
      sizes.  Instead, I moved the calls to assert_file_size where the file
      is written.  The downside is that we lose the filename at this point,
      but it was only used for the very improbable case of ftell failing, so
      I think it's not a problem.
    - The actual writing of the index file is factored out to
      write_gdbindex_1, so it can be re-used for both index files.
    - While the "save gdb-index" command will now write two .gdb-index
      files, this patch does not update the gdb-add-index.sh script, this
      will come in a later patch.

    gdb/ChangeLog:

    YYYY-MM-DD  Simon Marchi  <[hidden email]>

        PR gdb/24445
        * dwarf-index-write.h (write_psymtabs_to_index): Add
        dwz_basename parameter.
        * dwarf-index-write.c (write_gdbindex): Move file writing to
        write_gdbindex_1.  Change return type void.
        (assert_file_size): Move up, remove filename parameter.
        (write_gdbindex_1): New function.
        (write_debug_names): Change return type to void, call
        assert_file_size.
        (struct index_wip_file): New struct.
        (write_psymtabs_to_index): Add dwz_basename parameter.  Move
        file logic to index_wip_file.  Write index for dwz file if
        needed.
        (save_gdb_index_command): Pass basename of dwz file, if present.
        * dwarf-index-cache.c (index_cache::store): Obtain and pass
        build-id of dwz file, if present.
        * dwarf2read.c (struct dwz_file): Move to dwarf2read.h.
        (dwarf2_get_dwz_file): Likewise.
        * dwarf2read.h (struct dwz_file): Move from dwarf2read.c.
        (dwarf2_get_dwz_file): Likewise.

    gdb/testsuite/ChangeLog:

    YYYY-MM-DD  Tom de Vries  <[hidden email]>

        PR gdb/24445
        * gdb.dwarf2/gdb-index.exp (add_gdb_index): Update dwz file with
        generated index.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #15 from Simon Marchi <simark at simark dot ca> ---
Fixed by commit above.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Simon Marchi <simark at simark dot ca> ---
Marking as fixed for real.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24445] dwz multifile index not written to index cache

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24445

--- Comment #17 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <[hidden email]>:

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

commit 2b9f6e89d67b342593734d14f328625848fa5156
Author: Tom de Vries <[hidden email]>
Date:   Sun Jun 16 23:57:17 2019 +0200

    [gdb/contrib] Fix gdb/contrib/gdb-add-index.sh for dwz-m-ed execs

    Atm gdb-add-index.exp fails with target board cc-with-dwz-m.

    Fix this by updating gdb/contrib/gdb-add-index.sh to handle a dwz-m-ed
    executable.

    Tested on x86_64-linux.

    gdb/ChangeLog:

    2019-06-16  Tom de Vries  <[hidden email]>

        PR gdb/24445
        * contrib/gdb-add-index.sh: Update to handle dwz-m-ed executable.

--
You are receiving this mail because:
You are on the CC list for the bug.