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 8A5CC3858D1E for ; Mon, 19 Dec 2022 13:52:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A5CC3858D1E 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=1671457956; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=O5JZ3x5TFfl3BOEhpIl7deSAh8QN4mMk5k7OV9CT28M=; b=A7nM3j5dcOivGJaEUWkrcesB0Z+VJtzQD9rFHjSSg5NDSSw27lVRoYG/noCi8PcUNEEMhN EzBgvNgilL3c7m58MLLUYMO9Vsw5Itc/KcyYms1nWUNAX16jgBmKtpuJvJiYp2gIqsZLN4 89qcNFUWKAwmG2nFR3vAeBmVREjN1qc= 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-140-aUlWiKM7O8WOamXxBUbTsQ-1; Mon, 19 Dec 2022 08:52:35 -0500 X-MC-Unique: aUlWiKM7O8WOamXxBUbTsQ-1 Received: by mail-wm1-f69.google.com with SMTP id 9-20020a1c0209000000b003d1c0a147f6so6629470wmc.4 for ; Mon, 19 Dec 2022 05:52:34 -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:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=O5JZ3x5TFfl3BOEhpIl7deSAh8QN4mMk5k7OV9CT28M=; b=U2pKWed1Hppz2ObAjeq4oE+jRp1mO2cz6u10BiEQqI/noLo3IppxTrSyeykjQev7hK rGeEU34pMnUT2ZFYCxrNO6yedDYEn+0bDgsfyrwB7w1YJlgdNfL1NexY6Gaim0WLBV7j BP04hfbz08EVQn8e+JSM/UjRVidG2fnfJL6mEJm5p5+SZo993vjyM4ND/1+GZoAUVJE5 v9VZ2mZXCTiyekRCO1I2FaYsM4mF0ACj4zr+GUM9Fy1KUhRIVeofKmxiQbDMKu5EdaN9 GpSkUXzdrGo1mVkVI3vByUYa/4Ndppc07p8bn5fV8w+InUGfM+QKLo65MzBoE96DArMf ILOg== X-Gm-Message-State: ANoB5pnjaM428YN37OgIZ4FsNaKG7ur6lzdBpqliQQBdrdWacl80vcoE 2Jiw75QSgsKXNGoyBLiIJ4I8KcIhXmfZm6m4grN5Di0RWLbZxSOHYGTVdtu7Lgsirk2BNqcBA5x 70PmGdtaGqBmJjrH2ng6Ytg== X-Received: by 2002:a5d:45c5:0:b0:242:82a4:2bf4 with SMTP id b5-20020a5d45c5000000b0024282a42bf4mr25645048wrs.10.1671457953583; Mon, 19 Dec 2022 05:52:33 -0800 (PST) X-Google-Smtp-Source: AA0mqf6gNXYGlckrgHDhFloKS8JnxvJrtxKZuvtxt4JPTPchiMOvKejRPp1acltbpIRz2vnMr1oHhQ== X-Received: by 2002:a5d:45c5:0:b0:242:82a4:2bf4 with SMTP id b5-20020a5d45c5000000b0024282a42bf4mr25645042wrs.10.1671457953351; Mon, 19 Dec 2022 05:52:33 -0800 (PST) Received: from localhost ([31.111.84.238]) by smtp.gmail.com with ESMTPSA id u18-20020adfeb52000000b002423dc3b1a9sm10022771wrn.52.2022.12.19.05.52.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Dec 2022 05:52:33 -0800 (PST) From: Andrew Burgess To: 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: <5a78504a-8652-55c6-75ff-db6e0ab06690@arm.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> Date: Mon, 19 Dec 2022 13:52:31 +0000 Message-ID: <87fsdbzejk.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=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: 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. Thanks, Andrew