From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 4C61B3858D28 for ; Tue, 20 Dec 2022 08:43:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4C61B3858D28 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-out2.suse.de (Postfix) with ESMTPS id 795DA68685; Tue, 20 Dec 2022 08:43:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1671525794; 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=fhpTvuTmYFrnmqfJ8rK1DNAgms58Fg4mGLfKnms/cnY=; b=lVxwdRPrMf6Z4Rk3TTbjaxauN9XYXvugPvhpJ0mBEkAJAhPsudzPdx4gg1DzIwtRVMp1/J SbKoqzx/48A/OB7o8jRJY1HFEANu0p13vJd0YlS9P6hncgc0Qp8krTvxRdZuHfW0rbiAU8 WR+MFUg3mtZy/Ak/UzB14pY20kYsgqw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1671525794; 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=fhpTvuTmYFrnmqfJ8rK1DNAgms58Fg4mGLfKnms/cnY=; b=hgVYIi0prS40Mc4LSoJ6OMAYcNEyJb0/iKHSNjhK+mkUsrVln/SNS2FovdZCJEyj+NLWAI ACJ6orUMJslqd2Dg== 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 703FE13254; Tue, 20 Dec 2022 08:43:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id pdgwG6J1oWPpBwAAMHmgww (envelope-from ); Tue, 20 Dec 2022 08:43:14 +0000 MIME-Version: 1.0 Date: Tue, 20 Dec 2022 08:43:14 +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: <87fsdbzejk.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> User-Agent: Roundcube Webmail Message-ID: <21622d2af7f7c6231d916de6511dff97@suse.de> X-Sender: tdevries@suse.de Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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-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. Thanks, - Tom > Thanks, > Andrew