From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) by sourceware.org (Postfix) with ESMTPS id 271A33842400 for ; Fri, 10 Jul 2020 14:29:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 271A33842400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06AEQpL7194818; Fri, 10 Jul 2020 14:29:21 GMT Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 325y0aqsa0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 10 Jul 2020 14:29:21 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06AESP5i114876; Fri, 10 Jul 2020 14:29:21 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 325k42hp7q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Jul 2020 14:29:20 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 06AETIHe012088; Fri, 10 Jul 2020 14:29:18 GMT Received: from termi.oracle.com (/10.175.56.150) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Jul 2020 07:29:18 -0700 From: "Jose E. Marchesi" To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH V4 1/3] gdb: support for eBPF References: <20200710122530.32541-1-jose.marchesi@oracle.com> <20200710122530.32541-2-jose.marchesi@oracle.com> <199653b9-ee2a-b3cc-acbf-6a8293363407@simark.ca> Date: Fri, 10 Jul 2020 16:29:14 +0200 In-Reply-To: <199653b9-ee2a-b3cc-acbf-6a8293363407@simark.ca> (Simon Marchi's message of "Fri, 10 Jul 2020 09:51:38 -0400") Message-ID: <87blknqw91.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9677 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 spamscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007100102 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9677 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 malwarescore=0 clxscore=1015 impostorscore=0 phishscore=0 suspectscore=0 priorityscore=1501 bulkscore=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007100102 X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Fri, 10 Jul 2020 14:29:24 -0000 Hi Simon. I have noted a few mostly stylistic comments. I don't know much about eBPF, so I can't really comment on the behavior. Thanks for the review. > +/* Frame unwinder. > + > + XXX it is not clear how to unwind in eBPF, since the stack is not > + guaranteed to be contiguous, and therefore no relative stack > + addressing can be done in the callee in order to access the > + caller's stack frame. To explore with xBPF, which will relax this > + restriction. */ > + > +/* Given THIS_FRAME, return its ID. */ > + > +static void > +bpf_frame_this_id (struct frame_info *this_frame, > + void **this_prologue_cache, > + struct frame_id *this_id) > +{ > +} So if I understand correctly, at the moment there's no unwinding at all, there's always just one frame? What ID does that frame have? Would it still be good to assign something (constant) to *THIS_ID to make sure it's not random junk? Would setting null_frame_id make sense there?