From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 789FC3858D21 for ; Thu, 24 Oct 2024 10:59:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 789FC3858D21 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 789FC3858D21 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729767589; cv=none; b=qOlx7qj9y73BKkjkgKPapjQulMGJFjCKxIXT2yDFD7q5cPXx6myl8QIRwq71XZ54Y333vJ1YM5Sc/XU3sT1ZWh3KykSRaESb9lLj8N/SMmhAvA6Z3iyAaiIiUtQSbDdIGhxu8ACBAPwziTrU+E0MT2MSCLBWUOXzL/c+rymkv/M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729767589; c=relaxed/simple; bh=MDfc5tS3GH8uC5e3v64Q5/H+yjZNEoFg5Lce2sJ8KbE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=srxeOgLTE1z8KGB7kSW3tDB1i2Hhrqcn8FWqzebxKzs5bKxAbGzrQi3lV2a0WlNERNKP5DkJfHj46bsFQgjRaMgZtvB76I1gdLquqdW7k+W49XoXUDmj9fUkbeHSVbJubk9DbvlEHSe03cwHE5ltOYtpWKNi5n2Q8zOp0znULCY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729767582; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OOHTOEshQFYY7mye6uGVzMP1uVya9Yv+wX03vSThMTs=; b=Xdp0/2jiffzbQoRN5NqqBL4RYTyWN8nWDi0eTh/7UBRCpZsgrTcvYAARLdhfO///dpXBem k6ttOsHZ+3cWJhQ4YxTI+G2FcoWuekzg5O6QuCXcDNS1jMgPCj7WJ9wM29WFDtS17iCi6e JX/E9Qw6VYWigbXC1UkFHEDZTcWJM9E= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-99--KVAdyP4OtCgcRxAZmCZ8g-1; Thu, 24 Oct 2024 06:59:38 -0400 X-MC-Unique: -KVAdyP4OtCgcRxAZmCZ8g-1 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 600EA1955D75; Thu, 24 Oct 2024 10:59:37 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.45.225.77]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D3B9C1955E99; Thu, 24 Oct 2024 10:59:35 +0000 (UTC) From: Florian Weimer To: Claudiu Zissulescu-Ianculescu Cc: toolchain-patches_ww_grp , libc-alpha@sourceware.org Subject: Re: SFrame stack tracer In-Reply-To: <9bc1c439-b3f0-4833-9613-333eeffc629d@oracle.com> (Claudiu Zissulescu-Ianculescu's message of "Wed, 9 Oct 2024 20:09:33 +0300") References: <9bc1c439-b3f0-4833-9613-333eeffc629d@oracle.com> Date: Thu, 24 Oct 2024 12:59:32 +0200 Message-ID: <87sesl22cr.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Claudiu Zissulescu-Ianculescu: > Looking to dwarf stack unwinding support in glibc, it looks to me like > it is based on unwinder routines from libgcc. Correct. We have an old copy of the unwinder in the glibc sources, but most architectures do not use it. > Now, I would like to clarify if you would like to see the entire SFrame > stack tracer implementation added to glibc source code, i.e., without > any libgcc callbacks like in dwarf case. I think this makes sense. The SFrame data is generated by binutils from DWARF, so if we'd call a library, I suppose it would have to be something provided by binutils. (Although technically, the DWARF data that ends up in PT_GNU_EH_FRAME has been significantly rewritten by binutils, too.) Having the implementation in glibc proper also makes it easier to figure out how to discover signal frames because glibc controls the SA_RESTORER handshake on the userspace side. An unwinder separate from glibc would not have access to these internal glibc implementation details today. > As far as I can see, a SFrame stack tracer implementation will need some > architecture specific code added too, which may imply some extra > interfaces to be created on top of the suggested one in dl_find_object > structure. Yes, that's not going to be enough, but I think some form is required for getting SFrame data quickly. Thanks, Florian