From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 377653858421 for ; Tue, 20 Dec 2022 14:54:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 377653858421 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 588D73485D; Tue, 20 Dec 2022 14:54:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1671548098; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JPRCIcfNQGy2KLVUpuGe2nb6At/LZMDOo/bSebEM6Ko=; b=E4iUgJ3BOBZu3SlxIw0ft8nTjDySznuipWm6uozaS31BNYeZUDwuF5FOiJGq9tRce9ISAF H9c7n7cy9+TG5TqLGcpCaHjTThixZMaSGcMhoEkJPQRLeCwRjrKCybjkoolyjfL21Xs/u3 kCk3Fd7nqkflTBu79XPsJNaWQmiYNb8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1671548098; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JPRCIcfNQGy2KLVUpuGe2nb6At/LZMDOo/bSebEM6Ko=; b=9ooMhoy8bcTAOWOPfXtpubJpZx0kJnoKHoWBduJke5W4h0L6T1Nyv20PgjXcO3l/Pzn1pY Raj41hydzLAdBqCA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 4F6E113254; Tue, 20 Dec 2022 14:54:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Vuw0E8LMoWOzPgAAMHmgww (envelope-from ); Tue, 20 Dec 2022 14:54:58 +0000 MIME-Version: 1.0 Date: Tue, 20 Dec 2022 14:54:58 +0000 From: tdevries To: Andrew Burgess Cc: Luis Machado , Tom Tromey , Andrew Burgess via Gdb-patches Subject: Re: [PATCH 2/2] gdb/testsuite: new test for recent dwarf reader issue In-Reply-To: <87zgbixlcg.fsf@redhat.com> References: <87lengh250.fsf@tromey.com> <875yek2xdo.fsf@redhat.com> <286c40e2-3bde-91f2-32a2-485b6243bc93@arm.com> <877cys29o6.fsf@redhat.com> <5a78504a-8652-55c6-75ff-db6e0ab06690@arm.com> <87fsdbzejk.fsf@redhat.com> <21622d2af7f7c6231d916de6511dff97@suse.de> <874jtqz7oq.fsf@redhat.com> <87zgbixlcg.fsf@redhat.com> User-Agent: Roundcube Webmail Message-ID: X-Sender: tdevries@suse.de Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2022-12-20 13:20, Andrew Burgess wrote: > Andrew Burgess writes: > >> tdevries writes: >> >>> On 2022-12-19 13:52, Andrew Burgess via Gdb-patches wrote: >>>> Luis Machado writes: >>>> >>>>> On 12/15/22 11:22, Andrew Burgess wrote: >>>>>> Luis Machado writes: >>>>>> >>>>>>> Hi Andrew, >>>>>>> >>>>>>> On 12/9/22 19:24, Andrew Burgess via Gdb-patches wrote: >>>>>>>> Tom Tromey writes: >>>>>>>> >>>>>>>>>>>>>> "Andrew" == Andrew Burgess via Gdb-patches >>>>>>>>>>>>>> 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? LGTM. Though I wonder if we can make do with being less precise, and just do something like: ... proc assert_shared_library_debug_not_fully_expanded {} { gdb_test_lines "maint print objfiles $::libname" "" \ "Object file \[^\r\n\]*$::libname" \ -re-not "Symtabs:" } ... Thanks, - Tom > Thanks, > Andrew > > --- > > commit e1f51c1b3b37d96e679fa2698eb83a6a3a05eb53 > Author: Andrew Burgess > 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"} {