From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50626 invoked by alias); 24 Oct 2018 15:15:49 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 50287 invoked by uid 89); 24 Oct 2018 15:15:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Oct 2018 15:15:03 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4C78787648; Wed, 24 Oct 2018 15:15:01 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 67434648A9; Wed, 24 Oct 2018 15:15:00 +0000 (UTC) Subject: Re: [PATCH v3 3/3] Aarch64: Fix segfault when casting dummy calls To: Alan Hayward References: <20181011144905.66908-1-alan.hayward@arm.com> <20181011144905.66908-4-alan.hayward@arm.com> <95a5dd34-6815-f3f5-107c-13f4956b741e@redhat.com> <9290BC71-862C-48B1-97FD-A46C5D15A65C@arm.com> Cc: GDB Patches , nd From: Pedro Alves Message-ID: <201c7a49-ddf3-636a-f15a-eb9a4ccf284e@redhat.com> Date: Wed, 24 Oct 2018 15:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9290BC71-862C-48B1-97FD-A46C5D15A65C@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-10/txt/msg00548.txt.bz2 On 10/23/2018 05:08 PM, Alan Hayward wrote: > > >> On 19 Oct 2018, at 12:35, Pedro Alves wrote: >> > > > >>> to calculate lang_struct_return. This information is available in the >>> return_method enum. The fix is to simply use this instead. >>> >>> Add common test case using a shared library to ensure FUNC resolving. >> >> What does "common" mean here? > > By common I just meant not-aarch64-specific. I guess what I really meant > was any target that supported shared libraries. I see. (Suggest clarifying it in the commit log then.) > >> >> And what does "to ensure FUNC resolving" mean too, btw? >> AFAICT, the only reason to use a shared library is to >> compile it with or without debug information, right? >> Come to think of it, you could instead eliminate the >> shared library and compile a separate .o file instead, right? >> That would simplify the testcase a bit and expose it to more >> targets. >> > > I could only get the bug to expose itself when using a .so > > If I do the following using current HEAD then the bug is not present: > > g++ -c condbreak-solib-main.cc -o condbreak-solib-main.o -fno-inline > g++ -c condbreak-solib-lib.cc -o condbreak-solib-lib.o -fno-inline > g++ condbreak-solib-main.o condbreak-solib-lib.o > > It causes the type of the return value to be detected as > TYPE_CODE_PTR->TYPE_CODE_INT. Huh. That's really strange. Where is that pointer coming from? What does "ptype cmp3" say for you? (gdb) b foo if (int)cmp3("abc") == 1 Breakpoint 1 at 0x40048b (gdb) ptype cmp3 type = () (gdb) whatis cmp3 type = I wonder if what you're looking at is actually the malloc call? GDB will call malloc to allocate space for the "abc" string in the inferior. Look at the backtrace, see where the call is coming from. Actually, because of that, I think it would be better (more focused) to pass in a variable instead of "abc". You already have the unused variable "word" there: const char *word = "stuff"; So: (gdb) b foo if (int)cmp3(word) == 1 but please rename it to something else, because I tried that locally and there's another symbol called "word" in glibc's localeinfo.h, and gdb picks that one up. Also, is there a reason for the test to be a C++ program? If there's none, it'd be better to make it a C program, again to expose it to more targets. Thanks, Pedro Alves