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 B48D83858D1E for ; Thu, 8 Sep 2022 09:26:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B48D83858D1E 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 E04F51F8D4; Thu, 8 Sep 2022 09:26:01 +0000 (UTC) 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 C0C2013A6D; Thu, 8 Sep 2022 09:26:01 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id p+TULCm1GWPfRgAAMHmgww (envelope-from ); Thu, 08 Sep 2022 09:26:01 +0000 Message-ID: <1089e785-7092-95c8-9e91-f07f8348d98b@suse.de> Date: Thu, 8 Sep 2022 11:26:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH][gdb/testsuite] Use prototype to call libc functions Content-Language: en-US To: Kevin Buettner , Tom de Vries via Gdb-patches References: <20220905122706.GA23594@delia.home> <20220907104106.099b2c4d@f35-zws-1> From: Tom de Vries In-Reply-To: <20220907104106.099b2c4d@f35-zws-1> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2022 09:26:08 -0000 On 9/7/22 19:41, Kevin Buettner wrote: > On Mon, 5 Sep 2022 14:27:07 +0200 > Tom de Vries via Gdb-patches wrote: > >> Hi, >> >> On openSUSE Tumbleweed (using glibc 2.36), I run into: >> ... >> (gdb) print /d (int) munmap (4198400, 4096)^M >> Invalid cast.^M >> (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: \ >> get integer valueof "(int) munmap (4198400, 4096)" >> ... >> >> The problem is that after starting the executable, the symbol has type >> "void (*) (void)": >> ... >> (gdb) p munmap >> $1 = {} 0x401030 >> (gdb) start >> ... >> (gdb) p munmap >> $2 = {void (void)} 0x7ffff7feb9a0 <__GI_munmap> >> ... >> which causes the "Invalid cast" error. >> >> Looking at the debug info for glibc for symbol __GI_munmap: >> ... >> <0><189683>: Abbrev Number: 1 (DW_TAG_compile_unit) >> <189691> DW_AT_name : ../sysdeps/unix/syscall-template.S >> <189699> DW_AT_producer : GNU AS 2.39.0 >> <1><1896ae>: Abbrev Number: 2 (DW_TAG_subprogram) >> <1896af> DW_AT_name : __GI___munmap >> <1896b3> DW_AT_external : 1 >> <1896b4> DW_AT_low_pc : 0x10cad0 >> <1896bc> DW_AT_high_pc : 37 >> ... >> that's probably caused by this bit (or similar bits for other munmap aliases). >> >> This is fixed in gas on trunk by commit 5578fbf672e ("GAS: Add a return type >> tag to DWARF DIEs generated for function symbols"). >> >> Work around this (for say gas 2.39) by explicitly specifying the prototype for >> munmap. >> >> Likewise for getpid in a couple of other test-cases. >> >> Tested on x86_64-linux. >> >> Any comments? > > I have mixed feelings about patches like this. > > One the one hand, it's nice to have the test "fixed" so that it doesn't > fail. > > But, on the other hand, this failure found a problem with the debug info > in glibc, so fixing it as you did here will remove that test. > > Perhaps you could add a new test which will still fail when the debug info > incorrectly specifies that munmap has a void return type? Hi Kevin, thanks for the review. Alternatively, I could have marked these xfails, because they represent a failure in the environment, not in gdb. But I think that if we can avoid xfails by working around them, we should, because it simplifies testsuite maintenance. The fact that we no longer use that libc debuginfo is fine from the point of view of the gdb testsuite being a regression test suite for gdb. That does beg the question, where else would libc debuginfo be tested, and I don't know where, so perhaps we could have some dedicated gdb.libc testsuite subdir for that. I would put the test you propose in there. What is useful about the proposed test is that it eventually (once the new binutils release makes it into the various distros) will test the munmap debuginfo as generated by the fixed gas, that is, using DW_TAG_unspecified_type. We don't seem to have a dedicated test for this tag. There's some ada-specific bit in the code in gdb/dwarf/read.c handling this, which is supposed to be tested by gdb.ada/taft_type.exp, but how it will behave with the fixed gas, I have no idea. So, can we already test this now? Let's try: https://sourceware.org/bugzilla/show_bug.cgi?id=29558 . AFAIU, the generated dwarf is incorrect, so I've filed a gas PR for that. We can rewrite this into a gdb test-case, which would test gas debuginfo (so gdb.gas subdir?), but I guess we'd probably also want a dwarf assembly test-case. Thanks, - Tom