[ Test-case copied from PR25755 comment 0 III. ] Consider a test-case with sources test.c: ... extern int aaa; int main (void) { return 0; } ... and test2.c: ... int aaa = 33; ... With debug info for test.c, but not test2.c: ... $ gcc -c test.c -g; gcc -c test2.c; gcc test.o test2.o -g ... When trying to print the value of aaa, we get: ... $ gdb -batch a.out -ex "print aaa" 'aaa' has unknown type; cast it to its declared type ... Strictly speaking this is a regression since commit d321419811 "[gdb] Use partial symbol table to find language for main", before we'd have: ... $ gdb -batch a.out -ex "print aaa" $1 = 33 ... But there's nothing wrong with the commit, we just have to make explicit what was done implicitly before to get the same behaviour back: ... $ gdb -batch a.out -ex "maint expand-symtabs test.c" -ex "print aaa" $1 = 33 ... [ If we'd split the test.c source into a part with main, and a part with the decl, we'd be able to reproduce the same problem before the commit. ] What this demonstrates is the following: if we print the symtab for test.c, we have an aaa unresolved symbol that, combined with the minimal symbol address for aaa enables us to print the typed value: ... Symtab for file test.c at 0x2644ba0 Compilation directory is /home/vries Read from object file /home/vries/a.out (0x2637cb0) Language: c Blockvector: block #000, object at 0x2665880, 1 syms/buckets in 0x400497..0x4004a2 int aaa; unresolved int main(void); block object 0x2665770, 0x400497..0x4004a2 block #001, object at 0x26657d0 under 0x2665880, 1 syms/buckets in 0x400497..0x4004a2 typedef int int; block #002, object at 0x2665770 under 0x26657d0, 0 syms/buckets in 0x400497..0x4004a2, function main ... But there's _no_ psymtab equivalent: ... Partial symtab for source file test.c (object 0x3699fe0) Read from object file /home/vries/a.out (0x3641cb0) Full symtab was read (at 0x3632610) Symbols cover text addresses 0x400497-0x4004a2 Address map supported - yes. Depends on 0 other partial symtabs. Global partial symbols: `main', function, 0x400497 Static partial symbols: `int', type, 0x0 ... This seems to contradict the partial symtab design: if we want to find a symbol, we look for it in the partial symtabs. If we find it, we expand the partial symbtab into a full symtab, find the symbol in there and return it.
Tentative patch: ... diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index da702205c6..82f698cc03 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -7908,7 +7908,8 @@ scan_partial_symbols (struct partial_die_info *first_die, CORE_ADDR *lowpc, case DW_TAG_variable: case DW_TAG_typedef: case DW_TAG_union_type: - if (!pdi->is_declaration) + if (!pdi->is_declaration + || (pdi->tag == DW_TAG_variable && pdi->is_external)) { add_partial_symbol (pdi, cu); } ...
(In reply to Tom de Vries from comment #0) > This seems to contradict the partial symtab design: if we want to find a > symbol, we look for it in the partial symtabs. If we find it, we expand the > partial symbtab into a full symtab, find the symbol in there and return it. https://sourceware.org/gdb/wiki/Internals%20Partial-Symbol-Tables : ... It is a bug for GDB to behave one way when only a psymtab has been read, and another way if the corresponding symtab has been read in. Such bugs are typically caused by a psymtab that does not contain all the visible symbols. ... OK, that seems to confirm it.
submitted patch: https://sourceware.org/pipermail/gdb-patches/2020-April/167458.html
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=317d2668d01c7ddc9545029bf56d2b8c4d2bbfeb commit 317d2668d01c7ddc9545029bf56d2b8c4d2bbfeb Author: Tom de Vries <tdevries@suse.de> Date: Wed Apr 22 08:38:44 2020 +0200 [gdb/symtab] Store external var decls in psymtab Consider a test-case consisting of source file test.c: ... extern int aaa; int main (void) { return 0; } ... and test-2.c: ... int aaa = 33; ... compiled with debug info only for test.c: ... $ gcc -c test.c -g; gcc -c test2.c; gcc test.o test2.o -g ... When trying to print aaa, we get: ... $ gdb -batch a.out -ex "print aaa" 'aaa' has unknown type; cast it to its declared type ... but with -readnow we have: ... $ gdb -readnow -batch a.out -ex "print aaa" $1 = 33 ... In the -readnow case, the symbol for aaa in the full symtab has LOC_UNRESOLVED, and the symbol type is combined with the minimal symbol address, to read the value and print it without cast. Without the -readnow, we create partial symbols, but the aaa decl is missing from the partial symtabs, so we find it only in the minimal symbols, resulting in the cast request. If the aaa decl would have been in the partial symtabs, it would have been found, and the full symtab would have been expanded, after which things would be as with -readnow. The function add_partial_symbol has a comment on the LOC_UNRESOLVED + minimal symbol addres construct at DW_TAG_variable handling: ... else if (pdi->is_external) { /* Global Variable. Don't enter into the minimal symbol tables as there is a minimal symbol table entry from the ELF symbols already. Enter into partial symbol table if it has a location descriptor or a type. If the location descriptor is missing, new_symbol will create a LOC_UNRESOLVED symbol, the address of the variable will then be determined from the minimal symbol table whenever the variable is referenced. ... but it's not triggered due to this test in scan_partial_symbols: ... case DW_TAG_variable: ... if (!pdi->is_declaration) { add_partial_symbol (pdi, cu); } ... Fix this in scan_partial_symbols by allowing external variable decls to be added to the partial symtabs. Build and reg-tested on x86_64-linux. The patch caused this regression: ... (gdb) print a_thread_local^M Cannot find thread-local storage for process 0, executable file tls/tls:^M Cannot find thread-local variables on this target^M (gdb) FAIL: gdb.threads/tls.exp: print a_thread_local ... while without the patch we have: ... (gdb) print a_thread_local^M Cannot read `a_thread_local' without registers^M (gdb) PASS: gdb.threads/tls.exp: print a_thread_local ... However, without the patch but with -readnow we have the same FAIL as with the patch (filed as PR25807). In other words, the patch has the effect that we get the same result with and without -readnow. This can be explained as follows. Without the patch, and without -readnow, we have two a_thread_locals, the def and the decl: ... $ gdb -batch outputs/gdb.threads/tls/tls \ -ex "maint expand-symtabs" \ -ex "print a_thread_local" \ -ex "maint print symbols" \ | grep "a_thread_local;" Cannot read `a_thread_local' without registers int a_thread_local; computed at runtime int a_thread_local; unresolved ... while without the patch and with -readnow, we have the opposite order: ... $ gdb -readnow -batch outputs/gdb.threads/tls/tls \ -ex "maint expand-symtabs" \ -ex "print a_thread_local" \ -ex "maint print symbols" \ | grep "a_thread_local;" Cannot find thread-local storage for process 0, executable file tls/tls: Cannot find thread-local variables on this target int a_thread_local; unresolved int a_thread_local; computed at runtime ... With the patch we have the same order with and without -readnow, but just a different one than before without -readnow. Mark the "Cannot find thread-local variables on this target" variant a PR25807 kfail. gdb/ChangeLog: 2020-04-22 Tom de Vries <tdevries@suse.de> PR symtab/25764 * dwarf2/read.c (scan_partial_symbols): Allow external variable decls in psymtabs. gdb/testsuite/ChangeLog: 2020-04-22 Tom de Vries <tdevries@suse.de> PR symtab/25764 * gdb.base/psym-external-decl-2.c: New test. * gdb.base/psym-external-decl.c: New test. * gdb.base/psym-external-decl.exp: New file. * gdb.threads/tls.exp: Add PR25807 kfail.
Patch with test-case committed, marking resolved-fixed.