From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id D8FD33858284 for ; Sat, 24 Dec 2022 16:05:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D8FD33858284 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671897923; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=T2+7yhgpwFxQJm+IVsJSB/s5N5SMKjLpEwcUSCz79SA=; b=aXKMA8OxI81sP7zbz808oLY699CjIPe406lbE9wobooAFm3Ug0ETdUxFvaCojsrFEkuwes WEX3cJ9VLn1VO79yYpdjDG6922e3w09nj/IP8EIayPwKatAXyQAp8tBINmsZGovZMP1s3a O5aFyLg1AmMnNvFyFQkYp34Hd29ddfI= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-356-poPRrXFKPxWrDEsqAQZV6w-1; Sat, 24 Dec 2022 11:05:19 -0500 X-MC-Unique: poPRrXFKPxWrDEsqAQZV6w-1 Received: by mail-wm1-f69.google.com with SMTP id q21-20020a7bce95000000b003d236c91639so1677619wmj.8 for ; Sat, 24 Dec 2022 08:05:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=T2+7yhgpwFxQJm+IVsJSB/s5N5SMKjLpEwcUSCz79SA=; b=qKp6yXtkwZ9U6xgE+TDCsrsYs+X92zlQVQ6SJ5DoG0W2ZgB9BV8jZ5g18dQKLcZyfM 60HVaUwdgw6Fd1sr86FwDVD6+JU0yzIDlxgKptzioEiabXy02gGP7Xc7l32BU1mzt4Fe 9bW06pF4GMaxr+7qcwWX3b8X5QlA/mvS93W1Mhd0F46tYXiNQlImX+peniuHkPUi2iNf ZNwW0uca0vt3sN4ECZY4GGA3GL2bPyAC9G1ALukkfhZQhl98eJENmPcdglIuEocRaV5p PV6RGrA0UqSIcXTIliYDOoozErLtgasA1qklDAPISDpohMwudT7r6OTvnCTfPqntnN1P /l6g== X-Gm-Message-State: AFqh2kpUJZl87QqH9PM4vqQmlzOmKgauPoTuOarTXgGmOUJ7jOYd/meN M94Jvqt6uav3PE3bik6S8VEOnVtMyIS9eYDgyy1Efh26DtYOnVFiJO2tnTSk1t8d2mbWR578RHz LNPQczo6+e5+5rR8ui6TS9A== X-Received: by 2002:a05:600c:4d25:b0:3d3:5b7a:1791 with SMTP id u37-20020a05600c4d2500b003d35b7a1791mr11336558wmp.41.1671897917654; Sat, 24 Dec 2022 08:05:17 -0800 (PST) X-Google-Smtp-Source: AMrXdXuN+ZBKfQXZcEV0lCnsTpT1B3Pg/kPV+s/dBBFQs5Voj61Rybqxk8wY7AZT4TfB5LU3lVy0UA== X-Received: by 2002:a05:600c:4d25:b0:3d3:5b7a:1791 with SMTP id u37-20020a05600c4d2500b003d35b7a1791mr11336543wmp.41.1671897917360; Sat, 24 Dec 2022 08:05:17 -0800 (PST) Received: from localhost ([31.111.84.238]) by smtp.gmail.com with ESMTPSA id y22-20020a1c4b16000000b003d01b84e9b2sm8072595wma.27.2022.12.24.08.05.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Dec 2022 08:05:16 -0800 (PST) From: Andrew Burgess To: tdevries 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: 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> Date: Sat, 24 Dec 2022 16:05:15 +0000 Message-ID: <87wn6gyeh0.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: tdevries writes: > 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 for that suggestion Tom, that really is much better that what I had. I've taken your suggestion and pushed the fix to master. My final patch is below. Thanks, Andrew --- commit 3a98808c164b36c7023bd80fc6b019cbe6274365 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 single 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..30e224fb439 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 @@ -46,46 +47,10 @@ if {[readnow]} { # library has been fully expanded or not. Return true if the debug # 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" { - 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" - } - 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" - } - exp_continue - } - -re "^(\[^\r\n\]+):\r\n\r\n" { - set libname $expect_out(1,string) - if {$libname == $::objdso} { - set library_expanded "yes" - } - exp_continue - } - -re "^$::gdb_prompt $" { - gdb_assert {[string equal $library_expanded "yes"] \ - || [string equal $library_expanded "no"]} \ - $gdb_test_name - } - -re "^(\[^\r\n:\]*)\r\n" { - exp_continue - } - } - - return [expr $library_expanded == "no"] +proc assert_shared_library_debug_not_fully_expanded {} { + gdb_test_lines "maint print objfiles $::libname" "" \ + "Object file \[^\r\n\]*$::libname" \ + -re-not "Symtabs:" } foreach_with_prefix type_name {"short" "int" "long" "char"} { @@ -93,7 +58,7 @@ foreach_with_prefix type_name {"short" "int" "long" "char"} { with_test_prefix "before sizeof expression" { # Check that the debug information for the shared library has # not yet been read in. - gdb_assert { [shared_library_debug_not_fully_expanded] } + assert_shared_library_debug_not_fully_expanded } # Evaluate a sizeof expression for a builtin type. At one point GDB @@ -106,7 +71,7 @@ foreach_with_prefix type_name {"short" "int" "long" "char"} { with_test_prefix "after sizeof expression" { # Check that the debug information for the shared library has not # yet been read in. - gdb_assert { [shared_library_debug_not_fully_expanded] } + assert_shared_library_debug_not_fully_expanded } } }