Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5934267ybi; Wed, 12 Jun 2019 10:58:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqxpFZfRVbll9+txfYRgqeQkmC1Nv3MIzu4JiLQMNCDc8iCAKuZkhGNXDJsjSDZk0gTld5m6 X-Received: by 2002:a63:4e10:: with SMTP id c16mr25930261pgb.214.1560362331381; Wed, 12 Jun 2019 10:58:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560362331; cv=none; d=google.com; s=arc-20160816; b=WEp8D4SZf4rUxOk0iPijUsJEf0Gr0fVa/vxaXL+k8kfjZ49V/WVCoNfFzgm0DF/Wsx P6R3lfvCNXLSQgTMeLn0ydYix36um6P6vBcho8fA3pWOjo3phBv5sudWSxKO9bkLSde0 Ls0k4PCQtSeVCsLPRPm/BTfncfayniz/xG5P7Px/EFH9gQl6BzkxDasrcv2L18DBO07y Z3Q+jp3IYhhlDuJsQCTbYGcXl9K5MfThnb6wpNOCYITBFiY63eodWzEgbtLXVkKP2CEH oEMOhL5piOxo9TITTDkgvuYe37r91Y8cdxOrmOUpD74ggEtPvuDBc7DH8jsEvhx884X1 8yhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Mglf2MUfAiZX5HqbJlG+K6F4nWSHXdIHuAMkpYmw44w=; b=h5HBU+u4LRzhRxb+mr8SnPHQoRcoTp31mU3koIHGYp7D06PZANb4hZcWiniaTeQK7T KJDyHp0ILawWhQRQe1Yll1Le+3m3RpXauUeE/FTTMDZZDrT0sZVBBH4juNKMtj/z2mOU JxDlaTTwTODd0vADCRPp8dDsmqHVNZM1YvWC+Q05ChGRiZKTxo77Nk6ARJphPcHblo3G Tr/BB0Qd2v/ziKWt3/aKKv+M7qIm/yLZqZv469qZqaI+zdjcfOXHfkwi/zTg9PfwuOy6 w8bfXcLEWDuZvB2YL+zxAnC6DlZq681w+3piNxZEKRJo2OAgyDd7Kj3KIwxbn5vYYcvX XW0g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b17si445591pjq.20.2019.06.12.10.58.36; Wed, 12 Jun 2019 10:58:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2439032AbfFLNK0 (ORCPT + 99 others); Wed, 12 Jun 2019 09:10:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:46866 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729528AbfFLNK0 (ORCPT ); Wed, 12 Jun 2019 09:10:26 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C24A420874; Wed, 12 Jun 2019 13:10:24 +0000 (UTC) Date: Wed, 12 Jun 2019 09:10:23 -0400 From: Steven Rostedt To: Josh Poimboeuf Cc: Peter Zijlstra , Kairui Song , Alexei Starovoitov , Song Liu , lkml , Kernel Team , Alexei Starovoitov , Daniel Borkmann , "bpf@vger.kernel.org" Subject: Re: Getting empty callchain from perf_callchain_kernel() Message-ID: <20190612091023.6bccf262@gandalf.local.home> In-Reply-To: <20190612030501.7tbsjy353g7l74ej@treble> References: <20190522140233.GC16275@worktop.programming.kicks-ass.net> <20190522174517.pbdopvookggen3d7@treble> <20190522234635.a47bettklcf5gt7c@treble> <20190523133253.tad6ywzzexks6hrp@treble> <20190523152413.m2pbnamihu3s2c5s@treble> <20190524085319.GE2589@hirez.programming.kicks-ass.net> <20190612030501.7tbsjy353g7l74ej@treble> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 11 Jun 2019 22:05:01 -0500 Josh Poimboeuf wrote: > Right now, ftrace has a special hook in the ORC unwinder > (orc_ftrace_find). It would be great if we could get rid of that in > favor of the "always use frame pointers" approach. I'll hold off on > doing the kpatch/kprobe trampoline conversions in my patches since it > would conflict with yours. Basically, IIUC, what you are saying is that the ftrace trampoline should always store the %sp in %rb even when CONFIG_FRAME_POINTER is not enabled? And this can allow you to remove the ftrace specific code from the orc unwinder? -- Steve > > Though, hm, because of pt_regs I guess ORC would need to be able to > decode an encoded frame pointer? I was hoping we could leave those > encoded frame pointers behind in CONFIG_FRAME_POINTER-land forever...