From: Andrew Burgess <aburgess@redhat.com>
To: tdevries <tdevries@suse.de>
Cc: Luis Machado <luis.machado@arm.com>, Tom Tromey <tom@tromey.com>,
Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/2] gdb/testsuite: new test for recent dwarf reader issue
Date: Tue, 20 Dec 2022 13:20:47 +0000 [thread overview]
Message-ID: <87zgbixlcg.fsf@redhat.com> (raw)
In-Reply-To: <874jtqz7oq.fsf@redhat.com>
Andrew Burgess <aburgess@redhat.com> writes:
> tdevries <tdevries@suse.de> writes:
>
>> On 2022-12-19 13:52, Andrew Burgess via Gdb-patches wrote:
>>> Luis Machado <luis.machado@arm.com> writes:
>>>
>>>> On 12/15/22 11:22, Andrew Burgess wrote:
>>>>> Luis Machado <luis.machado@arm.com> writes:
>>>>>
>>>>>> Hi Andrew,
>>>>>>
>>>>>> On 12/9/22 19:24, Andrew Burgess via Gdb-patches wrote:
>>>>>>> Tom Tromey <tom@tromey.com> writes:
>>>>>>>
>>>>>>>>>>>>> "Andrew" == Andrew Burgess via Gdb-patches
>>>>>>>>>>>>> <gdb-patches@sourceware.org> writes:
>>>>>>>>
>>>>>>>> Thank you for doing this.
>>>>>>>>
>>>>>>>> Andrew> - However, GDB checks each partial symbol using multiple
>>>>>>>> languages,
>>>>>>>> Andrew> not just the current language (C in this case), so,
>>>>>>>> when GDB
>>>>>>>> Andrew> checks using the C++ language, the symbol name is
>>>>>>>> first demangled,
>>>>>>>> Andrew> the code that does this can be found
>>>>>>>> Andrew> lookup_name_info::language_lookup_name. As the
>>>>>>>> demangled form of
>>>>>>>> Andrew> 'signed int' is just 'int', GDB then looks for any
>>>>>>>> symbols with
>>>>>>>> Andrew> the name 'int', most partial symtabs will contain such
>>>>>>>> a symbol,
>>>>>>>> Andrew> so GDB ends up expanding pretty much every symtab.
>>>>>>>>
>>>>>>>> It's a pedantic point but what happens here is name
>>>>>>>> canonicalization,
>>>>>>>> not demangling. Demangling is just used to refer to the
>>>>>>>> translation
>>>>>>>> from a name like "_Zmumble" to "something::else" -- that is, the
>>>>>>>> input
>>>>>>>> is a linkage name and the output is a C++ name. Canonicalization
>>>>>>>> takes
>>>>>>>> a C++ name as input and returns the standard form, basically
>>>>>>>> dealing
>>>>>>>> with the fact that C++ (and as we discovered, C) has multiple
>>>>>>>> possible
>>>>>>>> spellings for some symbols.
>>>>>>>
>>>>>>> Please, be pedantic. My goal here was to better understand this
>>>>>>> code,
>>>>>>> there's no point me understanding it wrong.
>>>>>>>
>>>>>>> I'll reword that paragraph.
>>>>>>>
>>>>>>> Thanks for taking a look.
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>
>>>>>> I'm not saying you should investigate this, as it is a new test, but
>>>>>> I'm getting a lot of these messages for this test:
>>>>>>
>>>>>> ERROR: internal buffer is full.
>>>>>
>>>>> Happy to take a look at the problem.
>>>>>
>>>>> I guess the issue is coming from the gdb_test_multiple that I use in
>>>>> the
>>>>> new test script.
>>>>>
>>>>> I'm tried to write patterns that match and discard all the lines as
>>>>> they
>>>>> arrive from GDB. I guess you are seeing a pattern that I am not for
>>>>> some reason.
>>>>>
>>>>> Could you run just this test and attach the gdb.log file and I'll
>>>>> take a
>>>>> look. I probably just need to tweak one of the patterns a little.
>>>>>
>>>>> Thanks,
>>>>> Andrew
>>>>>
>>>>
>>>> I briefly looked into this. The problem seems to arise from the fact
>>>> that sometimes we don't have multiple lines for the "info sources"
>>>> output.
>>>>
>>>> Some sections are output in a single line. For example, one of them
>>>> has 133K characters. But each entry seems to be separated by a comma
>>>> character:
>>>>
>>>> ./elf/./elf/rtld.c, ./elf/../include/rtld-malloc.h,
>>>> ./elf/../sysdeps/generic/ldsodefs.h,
>>>> ./elf/../sysdeps/aarch64/dl-machine.h, ...
>>>
>>> Ahh, that would explain it. We don't appear to use 'info sources' that
>>> frequently in the testsuite. I wonder if you are also seeing failures
>>> on those other tests?
>>>
>>> gdb.asm/asm-source.exp
>>> gdb.dwarf2/dup-psym.exp
>>> gdb.dwarf2/dw2-filename.exp
>>>
>>>> It might be best (for the testsuite) if gdb outputs this data across
>>>> more lines.
>>>
>>> The other option might be to extend 'info sources' to allow filtering
>>> based on the objfile name, then we can use this in the testsuite to
>>> limit the output...
>>>
>>> ... or I wonder if we could trick GDB by setting the width to something
>>> small, the I guess the lines would be broken after the ',' characters.
>>>
>>> I'll have a play and see what I can come up with.
>>>
>>
>> I also ran into this issue on ubuntu 22.04.1 x86_64.
>>
>> AFAIK, the way we usually test for this type of information is "maint
>> print objfile", which is less verbose, and doesn't have long lines.
>
> I'm looking at this issue today, I'll give 'maint print objfile' a go.
> Thanks for the suggestion.
I was able to reproduce the buffer overflow errors. The patch below
addresses the issue for me.
Thoughts?
Thanks,
Andrew
---
commit e1f51c1b3b37d96e679fa2698eb83a6a3a05eb53
Author: Andrew Burgess <aburgess@redhat.com>
Date: Tue Dec 20 12:51:50 2022 +0000
gdb/testsuite: fix buffer overflow in gdb.base/signed-builtin-types.exp
In commit:
commit 9f50fe0835850645bd8ea9bb1efe1fe6c48dfb12
Date: Wed Dec 7 15:55:25 2022 +0000
gdb/testsuite: new test for recent dwarf reader issue
A new test (gdb.base/signed-builtin-types.exp) was added that made use
of 'info sources' to figure out if the debug information for a
particular object file had been fully expanded or not. Unfortunately
some lines of the 'info sources' output can be very long, this was
observed on some systems where the debug information for the
dynamic-linker was installed, in this case, the list of source files
associated with the dynamic linker was so long it would cause expect's
internal buffer to overflow.
This commit switches from using 'info sources' to 'maint print
objfile', the output from the latter command is more compact, but
also, can be restricted to a named object file.
With this change in place I am no longer seeing buffer overflow errors
from expect when running gdb.base/signed-builtin-types.exp.
diff --git a/gdb/testsuite/gdb.base/signed-builtin-types.exp b/gdb/testsuite/gdb.base/signed-builtin-types.exp
index e9784330fee..fdb9251758e 100644
--- a/gdb/testsuite/gdb.base/signed-builtin-types.exp
+++ b/gdb/testsuite/gdb.base/signed-builtin-types.exp
@@ -21,7 +21,8 @@ standard_testfile .c -lib.c
# Compile the shared library.
set srcdso [file join $srcdir $subdir $srcfile2]
-set objdso [standard_output_file lib${gdb_test_file_name}.so]
+set libname "lib${gdb_test_file_name}.so"
+set objdso [standard_output_file $libname]
if {[gdb_compile_shlib $srcdso $objdso {debug}] != ""} {
untested "failed to compile dso"
return -1
@@ -47,45 +48,39 @@ if {[readnow]} {
# information has NOT been fully expanded (which is what we want for this
# test).
proc shared_library_debug_not_fully_expanded {} {
- set library_expanded ""
- gdb_test_multiple "info sources" "" {
- -re "^info sources\r\n" {
+ set not_expanded true
+ gdb_test_multiple "maint print objfiles $::libname" "" {
+ -re "^maint print objfiles \[^\r\n\]+\r\n" {
exp_continue
}
- -re "^(\[^\r\n\]+):\r\n\\(Full debug information has not yet been read for this file\\.\\)\r\n\r\n" {
- set libname $expect_out(1,string)
- if {$libname == $::objdso} {
- set library_expanded "no"
- }
+
+ -re "^\\s*\r\n" {
+ exp_continue
+ }
+
+ -re "^Object file \[^\r\n\]+\r\n" {
exp_continue
}
- -re "^(\[^\r\n\]+):\r\n\\(Objfile has no debug information\\.\\)\r\n\r\n" {
- set libname $expect_out(1,string)
- if {$libname == $::objdso} {
- # For some reason the shared library has no debug
- # information, this is not expected.
- set library_expanded "missing debug"
- }
+
+ -re "^Cooked index in use\r\n" {
exp_continue
}
- -re "^(\[^\r\n\]+):\r\n\r\n" {
- set libname $expect_out(1,string)
- if {$libname == $::objdso} {
- set library_expanded "yes"
- }
+
+ -re "^Symtabs:\r\n" {
+ set not_expanded false
exp_continue
}
+
-re "^$::gdb_prompt $" {
- gdb_assert {[string equal $library_expanded "yes"] \
- || [string equal $library_expanded "no"]} \
- $gdb_test_name
+ pass $gdb_test_name
}
- -re "^(\[^\r\n:\]*)\r\n" {
+
+ -re "^\[^\r\n\]+\r\n" {
exp_continue
}
}
- return [expr $library_expanded == "no"]
+ return $not_expanded
}
foreach_with_prefix type_name {"short" "int" "long" "char"} {
next prev parent reply other threads:[~2022-12-20 13:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-08 15:38 [PATCH 0/2] New test for slow DWARF " Andrew Burgess
2022-12-08 15:38 ` [PATCH 1/2] gdb/testsuite: fix readnow detection Andrew Burgess
2022-12-08 15:38 ` [PATCH 2/2] gdb/testsuite: new test for recent dwarf reader issue Andrew Burgess
2022-12-09 18:18 ` Tom Tromey
2022-12-09 19:24 ` Andrew Burgess
2022-12-14 14:47 ` Luis Machado
2022-12-15 11:22 ` Andrew Burgess
2022-12-19 13:20 ` Luis Machado
2022-12-19 13:52 ` Andrew Burgess
2022-12-20 8:43 ` tdevries
2022-12-20 10:32 ` Andrew Burgess
2022-12-20 13:20 ` Andrew Burgess [this message]
2022-12-20 14:04 ` Luis Machado
2022-12-20 14:54 ` tdevries
2022-12-24 16:05 ` Andrew Burgess
2022-12-09 18:18 ` [PATCH 0/2] New test for slow DWARF " Tom Tromey
2022-12-14 10:25 ` Andrew Burgess
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zgbixlcg.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@arm.com \
--cc=tdevries@suse.de \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).