From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99842 invoked by alias); 11 Feb 2016 13:39:00 -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 99822 invoked by uid 89); 11 Feb 2016 13:39:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=single-step, singlestep, Hx-languages-length:2629, Who 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 11 Feb 2016 13:38:59 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 06755347DB0; Thu, 11 Feb 2016 13:38:58 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1BDcuZx013260; Thu, 11 Feb 2016 08:38:57 -0500 Message-ID: <56BC8EF0.4000202@redhat.com> Date: Thu, 11 Feb 2016 13:39:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Metzger, Markus T" CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH v2 3/3] btrace, frame: fix crash in get_frame_type References: <1454681922-2228-1-git-send-email-markus.t.metzger@intel.com> <1454681922-2228-3-git-send-email-markus.t.metzger@intel.com> <56B9D620.2020104@redhat.com> <56BA61C6.8060807@redhat.com> <56BB0A0D.80502@redhat.com> <56BB5872.2000604@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00348.txt.bz2 On 02/11/2016 09:51 AM, Metzger, Markus T wrote: >> -----Original Message----- >> From: Pedro Alves [mailto:palves@redhat.com] >> Sent: Wednesday, February 10, 2016 4:34 PM >> To: Metzger, Markus T >> Cc: gdb-patches@sourceware.org >> Subject: Re: [PATCH v2 3/3] btrace, frame: fix crash in get_frame_type >> >> On 02/10/2016 03:02 PM, Metzger, Markus T wrote: >> >>> No new fails there, as well (64-bit IA). >>> >>> I added a comment based on your statement that >> frame_unwind_caller_xxx >>> callers should check frame_unwind_caller_id and assert that >>> skip_artificial_frames does not return NULL. >>> >>> Info frame doesn't crash. >>> >>> (gdb) info frame >>> Stack level 0, frame at 0x0: >>> rip = 0x4005b0 in bar (tailcall-only.c:29); saved rip = 0x4005c2 >>> called by frame at 0x0 >> ^^^^^^^^^^^^^^^ >> >>> source language c. >>> Arglist at unknown address. >>> Locals at unknown address,Registers are not available in btrace >>> record history >>> >>> This is from a tailcall-only frame stack in replay mode using the tailcall-only >> test. >>> The real caller has not been recorded. >> >> Not sure how you got that, since "called by frame" seems to indicates that >> the frame was not TAILCALL_FRAME: > > That's the sentinel frame. I forgot to "up". Now it crashes;-) > > There are other cases where frame_unwind_caller_xxx callers don't check > frame_unwind_caller_id: > > gdb/mips-linux-tdep.c > gdb/glibc-tdep.c > gdb/obsd-tdep.c > gdb/tic6x-linux-tdep.c > gdb/sol2-tdep.c > gdb/nios2-linux-tdep.c > > They're used for skipping syscalls and ld.so. > > The latter should be called via gdbarch_skip_solib_resolver (gdbarch, stop_pc) > from infrun.c. > > Who is supposed to do the check in those cases? Maybe they are already OK? In the syscall cases, we're trying to determine the next PC where to place a breakpoint, in order to do a software single-step. If we don't know where the caller is, we can't single-step, so we should probably error out. OTOH, if the target_ops is record-like and we're single-stepping through the trace log, we shouldn't be trying to use software single-step at all. So I think those are probably OK. In the glibc_skip_solib_resolver case -- in theory, I guess it would be possible to construct a branch trace that records a tailcall to _dl_fixup, and that doesn't have any frame above that one? If we don't know where the caller is, we can't skip the resolver in one go, so best to do is probably to return 0, and let infrun's stepping logic continue single-stepping. Thanks, Pedro Alves