From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id 8E1353858D28 for ; Sat, 7 May 2022 00:52:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E1353858D28 Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 246KnApm019339 for ; Sat, 7 May 2022 00:52:39 GMT Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3frwntfh2w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 07 May 2022 00:52:38 +0000 Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 2470p4u0013492 for ; Sat, 7 May 2022 00:52:38 GMT Received: from nam04-mw2-obe.outbound.protection.outlook.com (mail-mw2nam08lp2170.outbound.protection.outlook.com [104.47.73.170]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com with ESMTP id 3fruj6gw88-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 07 May 2022 00:52:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ajTMfk0y+UsevqlE76lN5rgCUPatI1lEsn3Xkw+2G6hbxFTZVOUEkTw/wzuwCtOMbYjPvSSqdflXNVSh5c1bbqR+mAZWpydeVr5RejC5uYgA1+fdnOS/msccFBW5rD/ybfg6rL5PpJVzJtM/ksvk61XWkkvRVLiYvDXLA/ZlvWi/rHDW8V3zc+HyJR/GipPexwbgpqj5ZlkchDZn+9mf8kCxEFiA4wGrBXhbVwXbPldtG4J59UGGucERiJo4UUtFzDDvK8nbEe4RsZM06zi1PBTFppvKn6pI23mTMGCZGmzzYXX4M4DxBDDkH4zRME7Mre/KwdGTo5eyXmTwq7Dd9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pHoVJ/mD99QXbsFxf3ZT58EcUMB5HwLb6az05KtV9tU=; b=bA2eRdyoXkw6+eroZ4KrIzpu/11NSlEDw/OwrnrHpO51Mg68pwubd835FeOOqJoL8+iPtnrNpDpEEHRKI0eQhM1Vpr2Hyl1lLoWPSifBFhbdKnNZyisFnTfGNbnL68viEllRHV3dbIbdMeKmPSG+KI1dCrdJZdIICFZlBCwPdkvuirfOrmc+hdOCe0Ij8rK1VJhwnuDtuzbAsYWODiG2SB0M7pVPQFH66UzIVuTAoyObHgz50P2pFvo3ld87+UXY1KKDR4N8n6H5Tk1gddSdRqIYe4F/I6pKQei9AorYlxPp+XH6Z7EqxDGIJcM6PdD5XIUzL9Srjj0jROTADnO5VQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) by MWHPR10MB1517.namprd10.prod.outlook.com (2603:10b6:300:23::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.27; Sat, 7 May 2022 00:52:36 +0000 Received: from MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::c1ba:b4c:fe6f:d171]) by MWHPR1001MB2158.namprd10.prod.outlook.com ([fe80::c1ba:b4c:fe6f:d171%7]) with mapi id 15.20.5206.025; Sat, 7 May 2022 00:52:35 +0000 From: Indu Bhagat To: binutils@sourceware.org Subject: [PATCH,RFC 0/7] Definition and Implementation of CTF Frame format Date: Fri, 6 May 2022 17:52:16 -0700 Message-Id: <20220507005223.3093035-1-indu.bhagat@oracle.com> X-Mailer: git-send-email 2.31.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: MW2PR16CA0066.namprd16.prod.outlook.com (2603:10b6:907:1::43) To MWHPR1001MB2158.namprd10.prod.outlook.com (2603:10b6:301:2d::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: feecc0b3-759d-442b-cca5-08da2fc3e051 X-MS-TrafficTypeDiagnostic: MWHPR10MB1517:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: srAjZGzKOsON0T94pzvf2Jzl6FIf9UuvNlYriKR7elHevPl6Vghtx6I2kTAzQ4O1iRankApwrHYRpQ+03IArQf1xurCi/pofKc/hLRxJIxfB4oohfDIEpV2fGxQ30XWDymsS2UlNnI0+gD5bxA9hVnGtVAE7EVR7nkoNLN2la6CHhpa4zOM1/lkhwXz8UINf3IHVYI8P6xu5DX9x05vhfIIcMmmRiTWvJ6Jp5atDclJpMoVrHYhHf5f3/6XdYJS5yx4UjmMlIej0S+SK33xkR7eDVUO8T9Ye0st/oNumIjJykf8LFbxR8PSLPYtQ5fQBxXV5iLCUT6J1No2DeDgL+qUwUt35Q7bYPJu2qaDWYsaebW0Dgxcx60bhs1JuAhhATLbzzWy1L79mVxno6dofePMyNB2XSK6OOlc/w1QiGS/AOyoU/EGwnHiPNcGoMJDCgjHxf4v8rG3+BfvTj/4oFfHebp/7HcG46XwAD6xscLUj3qht9IQGO1U3tj3/+fGnCh1GjlaEvWe396PNN3t8Rhn4S+jn28ZQOTFyuRvoDAE9WxY+JIxRzLGwEr8RFH6cnh6t2axBlwHBpKWAJFqCBCEuSUceSxrWwdsH9VPN2Zg8FIeMGzvsLHQ8fKpNj5SYO+iJTvjbUV59lpiimEpFENHmRL4LyScbQhwbVSLxDlWf2wkYlnKaagu9wBUF1J3Q/OqCjxAxR2sNOgqRshS91EphFgqwnCwA9PEP/C/Kmefa31p+4AoABa2cbXKSKhC2k+XCV2QlIJv/5K8n78pjs24RYKQ2h1RdK9fQjbu7Gow= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR1001MB2158.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(186003)(2906002)(316002)(8936002)(38350700002)(2616005)(26005)(1076003)(38100700002)(6486002)(966005)(52116002)(6666004)(5660300002)(66946007)(66556008)(6506007)(36756003)(8676002)(83380400001)(44832011)(66476007)(508600001)(30864003)(86362001)(6916009)(6512007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?+oYRDhmwtynkRUQCAGTefA/yivhprix556e/6U40ezPEUpYzj13Qu4dOAlJU?= =?us-ascii?Q?eMenSpNEowUOJjA2dPu8shi/f+8C0xVbNNMPmVyrD7lCnlqqyeJDdmkRemYM?= =?us-ascii?Q?LiG4o+OIicxOt+RPpp0JtVXcZ+7K6V4m3LKhq553RZGLyjnZnkU2bM1wL/sD?= =?us-ascii?Q?0YiFV+aOn0Il7FLdFItN0zgoFwkiJtjpaWR6Di7yNA2/H25mT0gOqq5HJs7C?= =?us-ascii?Q?R5OY2+opUcDz1NSz4FLNJRfI/yx6Cc1xlIO444Qyvwy6Hx+jr2XtmRPAdUsz?= =?us-ascii?Q?+JgJvQ2GglLVbtehdCwRa1EjA+64ntsST6f6Y5cAyImIgXpGVqKTo9GT1if8?= =?us-ascii?Q?WsXFnSNAPTgCweJj7ZCbVmEdR+RBEQT4Q01hwFnZeDS+uZBxWx4D17I6Do/G?= =?us-ascii?Q?1MNCtgq66+EntKPib1S5ZOW4G75fCb6ZBoTnmjEQPhXi5A414PMLnSWynBFu?= =?us-ascii?Q?/m3I0tMcKBSfZRxdChinov9o8SRQr3yvh0TxzVIRWXIAoR43TW9H0HTF9yBQ?= =?us-ascii?Q?n6H0E+8qT5S+jfZfeHy08hFjGJWe2lNr8iKzxQQFFXWp41HupUHp7uxhuJYn?= =?us-ascii?Q?KUBWCE/fIPEVpqG3XP2UIIfq/Gof3xL/nWwvuYA4/CRokiZVIWT5gQOrJ5mL?= =?us-ascii?Q?RiKVVP4BiWh8LBU86+78+qfXv+J6VKeXkcaqCZjtTjL5hNTnjb/vwktBHS5E?= =?us-ascii?Q?n+Dh/yyYuo195kEKuMo5uIl64/F7KHWmIETCFk0Fxm/DRwyZCvcxmsdTShaA?= =?us-ascii?Q?CXBrFL0+7vPWFqXHW/a5keXnYjJ1drLnbcwD2dCBuHDnYRNg/jKPDXJN5OG6?= =?us-ascii?Q?Kyn6i2jO2hM/enxt+cvTQ2eGgx7doSkoxwwMxg9p3E5XFy3wtSbunvyNuDGw?= =?us-ascii?Q?PhzUv33qacvVuNzdtqTmSLbDvMrQJdffAFvna1ppI9l5ZJDM8xeLShhzGKc+?= =?us-ascii?Q?89ixmbsbyrGYNxeZhrxD/Q2fPCaLlDvzkKG0aiI7PfsJT1njAWKEHWfW3LUF?= =?us-ascii?Q?K+pKpuj/fM/apv2srXGdim1tjEPMbNH22alMmk1cZQInPuXi1df+uUxzZhPr?= =?us-ascii?Q?ZmDYiEUsGsrJB8ILliouWBgd7dI9OlTNTse5YKhNk+facDE2MQQ5rvj5CB3B?= =?us-ascii?Q?1QZDyqhnK2InSuuntq2OTPFmP9DIdXI1WbXIlvbFk87DEXu+fnbyGK1OmIRR?= =?us-ascii?Q?9de5nxCLh0kVCPuHXagtK47R8/GKnKmqKZRlZEmJdELPT2uID7Fnd+e7Uol/?= =?us-ascii?Q?ADlE5CoPmdEQu8gkBnUYHDYVKZpceDP8tCLmScJrNvC6R5rLYKz2vkz4Jkn8?= =?us-ascii?Q?l/h8wzolMMnxRwTs1Baf+LUtSmL9zB1s3TI/MztpzDY6C8mjpQeeQiI7SD8O?= =?us-ascii?Q?oolZzfrBsyyLIDof3rsfZxoIK36Bmo8xu+4yRRUJS0tS3arYAGOTfCkUz29z?= =?us-ascii?Q?TTKvDSVkOavQlQI/YSCKnuZjzqv9MMAcQ0D4kWvRAa9lDd0xcTaubLrvYpeo?= =?us-ascii?Q?ad6N83Pf4S0zDMYD+pz0HS3vB7d5go5NDpZlGMemTXeFxXleBhtZGuM6NlFg?= =?us-ascii?Q?vDt3ecVbhidobaj5oJ3LYPTuuQQONN+ghBW+W6IIky7DkRGXfVHuwE+0t9Nx?= =?us-ascii?Q?ABDkuVyfsSNudxFT7XFx+UBTUaA7s1UxURne1S6Nci0NLfNXSNtljece2NAl?= =?us-ascii?Q?l2l87RJ77SRuUH8pdwY8o7HNUKmSL6dO3QbgdExg7QIxCnFfa7B2JxUuWQ+7?= =?us-ascii?Q?9pb+0QN8wg=3D=3D?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: feecc0b3-759d-442b-cca5-08da2fc3e051 X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2158.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2022 00:52:35.7119 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VDl1V2eYDrxCzCo/9GXCg8LjEH2S/xQnlvhgpJDww8wmyUWhn332CjBFbsAJYSnxO3fl09yyl6KNkGy9HQgzkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB1517 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-05-06_07:2022-05-05, 2022-05-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 mlxlogscore=999 adultscore=0 phishscore=0 suspectscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205070003 X-Proofpoint-ORIG-GUID: 3NmeY3X4QjJ7Ze_vl5VA7fGfsUiI8HM7 X-Proofpoint-GUID: 3NmeY3X4QjJ7Ze_vl5VA7fGfsUiI8HM7 X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2022 00:52:47 -0000 Hello folks, This patch series is to invite comments, feedback and discussion on the CTF Frame format. At the GNU Tools Track at LPC 2021 (https://linuxplumbersconf.org/event/11/contributions/1003/), it was proposed to create a lightweight and compact unwind format intended to be kept in binaries and to be used by online debugging tools like stack unwinders. We are calling this format "CTF Frame". Some notes around the motivation and use case of the CTF Frame format were previously also discussed here https://sourceware.org/pipermail/binutils/2021-December/118880.html. This patch series contains: - The definition of the CTF Frame format. This is the binary representation of what does in the .ctf_frame section and is generated using the CFI assembler directives. - A little and simple library that provides encoders and decoders to write and read the CTF Frame binary data - libctfframe. - Implementation in assembler and linker to create and merge .ctf_frame sections. - Support for CTF Frame in readelf and objdump. - A very simple example online unwinder that is based in CTF Frame. For simplicity it provides the same interface as the backtrace(3) glibc call. - For completeness, build system changes for gdb/ and sim/. These changes are necessary to accommodate the newly created libctfframe library. CTF Frame format ---------------- CTF Frame format provides basic unwind information for programs and libraries via a .ctf_frame section. The .ctf_frame section is an allocatable, loadable data section in a segment of its own (new segment introduced as PT_GNU_CTF_FRAME) in ELF linked binaries. The CTF Frame format specifies the minimal necessary unwind information, i.e., information needed to recover only the CFA and the return address (RA) for all insns of a program. This information is a subset of what .eh_frame can convey: .eh_frame specifies how to resurrect all callee-saved registers, if need be. CTF Frame format is meant to be independent of the CTF type format: a .ctf_frame section can have existence independent of the .ctf section. Type information of the sort provided by CTF is not needed to unwind stack frames, so CTF Frame is totally independent from CTF. The term "CTF" in the name, however, is a deliberate choice as the CTF Frame format aligns well to the core principles of the CTF debug format: compact and simple. Further, in future, there will be support to gather the C types and the original value of function arguments for generating more meaninful backtraces. Some of this information will come from the .ctf section. But the unwind information in .ctf_frame section will remain usable with or without a .ctf section. In other words, that future functionality will rely on additional section(s) that can establish the relationship between unwind info in .ctf_frame section with the type info in the .ctf section. A CTF Frame section consists of a CTF Frame header, a list of CTF FDEs (CTF Frame Description Entries) and a list of CTF FREs (CTF Frame Row Entries). A CTF FRE serves a set of consecutive PCs, all of which have the same unwind information. Together with the associated CTF FDE, each CTF FRE forms a self-sufficient record to recover the CFA and RA of the set of PCs served by the CTF FRE. For more details on the CTF Frame format, please see the ctf-frame.h header file included in this series. The CTF Frame format supports x86_64 and aarch64 at this time. Compared to the size of the unwind information in .eh_frame (plus .eh_frame_hdr), .ctf_frame sections currently are faring OK. Here is ratio of the size of (.ctf_frame) over size of (.eh_frame+.eh_frame_hdr) for x86_64 and aarch64 for some randomly chosen programs in binutils: ratio = (.ctf_frame / (.eh_frame+.eh_frame_hdr)) --------------------------------------------------- program | [x86_64] ratio | [aarch64] ratio --------------------------------------------------- addr2line | 1.13 | 0.67 ar | 1.03 | 0.70 as | 1.00 | 0.73 c++filt | 1.08 | 0.64 elfedit | 1.03 | 0.66 gprof | 1.06 | 0.71 ld | 1.02 | 0.73 nm | 1.07 | 0.69 objcopy | 1.08 | 0.72 objdump | 1.08 | 0.73 size | 1.10 | 0.67 strings | 1.09 | 0.67 On an average, for x86_64, the .ctf_frame sections are about 6% larger than the .eh_frame* sections. There exist ways to improve .ctf_frame sizes on x86_64, which have not been explored in depth yet. One of the causes of the bloat in .ctf_frame sections is known to be the unwind information for PLT entries. The .eh_frame unwind information for PLT section on x86_64 is particularly compact as it can be encoded using a DWARF expression which evaluates "rsp + 8 + ((((rip & 15)>= 11)? 1 : 0)<< 3)" for each value of rip in the PLT section at run-time. The CTF Frame format does not support expressions at all, causing a bloat because subsequent PCs in the PLT sections have different unwind rules, landing each PC of the PLT entry an entry of its own in the CTF Frame section (each PC hence has a distinct CTF Frame row entry). This issue can be resolved by incorporating some more careful design ideas to compactly encode information in the CTF Frame Row Entries, such that it exploits the "regular pattern" in the unwind information for the PLT entries. High-level implementation notes ------------------------------- Creation and Linking: The creation of .ctf_frame section is the onus of the assembler which creates the section by using the .cfi_* directives embedded by the compiler. If .ctf_frame section is to be created, the compiler must emit a ".ctf_frame" in the .cfi_sections directive. Because the CTF Frame format does not support complex expressions, those functions whose .cfi_ directives specify complex expressions are skipped. In practice, DWARF CFA expressions are not very prevalent for CFA, RA recovery. At link-time, the linker merges the input .ctf_sections by combining the contents and sorting the FDEs on the start PC. This helps an unwinder retrieve the relevant unwind information quickly. The libctfframe library: The linker uses a library called libctfframe which provides the basic functionality needed to decode a .ctf_frame section, and also to encode and eventually write out the .ctf_frame in its binary format. Unwinder: A basic unwinder based on CTF Frame format is relatively simple to write. We are providing one as an example and proof of concept. Testing ------- Testing on x86_64 and aarch64 looks promising so far - basic unwinding is working. This patch series is work in progress. There still remain open issues to be resolved, crude code stubs to be revisited and addition of testsuites. This will be taken care of in subsequent iterations of the series. Please comment and provide feedback, it will help shape the format. Here are a few of the aspects that particularly need discussion: 1. What is a good place for an unwinder based on CTF Frame format ? Currently to facilitate discussion, it is presented in a library of its own: libctfbacktrace which, in turn, uses the libctfframe library for decoding the .ctf_frame section for unwinding. We brainstormed a bit about the possible candidates being libbacktace, libgcc or libunwind ? Are there any recommendations ? 2. Are there some ideas for smartly dealing with the issue of bloat caused by the CTF Frame unwind information for the PLT entries ? Thanks, Indu Bhagat (5): ctf-frame.h: Add CTF Frame format definition gas: generate .ctf_frame bfd: linker: merge .ctf_frame sections readelf/objdump: support for CTF Frame section gdb: sim: buildsystem changes to accommodate libctfframe Weimin Pan (2): libctfframe: add the CTF Frame library unwinder: generate backtrace using CTF Frame format Makefile.def | 5 + Makefile.in | 1289 ++- bfd/Makefile.am | 6 +- bfd/Makefile.in | 7 +- bfd/bfd-in2.h | 1 + bfd/configure | 2 +- bfd/configure.ac | 2 +- bfd/elf-bfd.h | 55 + bfd/elf-ctf-frame.c | 490 + bfd/elf.c | 31 + bfd/elf64-x86-64.c | 97 +- bfd/elflink.c | 52 + bfd/elfxx-x86.c | 303 +- bfd/elfxx-x86.h | 46 + bfd/section.c | 1 + binutils/Makefile.am | 10 +- binutils/Makefile.in | 10 +- binutils/doc/binutils.texi | 4 + binutils/doc/ctfframe.options.texi | 10 + binutils/objdump.c | 74 + binutils/readelf.c | 44 + configure | 2 +- configure.ac | 2 +- gas/Makefile.am | 3 + gas/Makefile.in | 22 +- gas/as.h | 10 +- gas/config/tc-aarch64.c | 42 + gas/config/tc-aarch64.h | 29 + gas/config/tc-i386.c | 46 + gas/config/tc-i386.h | 26 + gas/config/tc-xtensa.c | 1 + gas/ctffreopt.c | 158 + gas/dw2gencfi.c | 30 +- gas/dw2gencfi.h | 1 + gas/gen-ctf-frame.c | 1188 +++ gas/gen-ctf-frame.h | 142 + gas/write.c | 13 + gdb/Makefile.in | 8 +- gdb/acinclude.m4 | 4 +- gdb/configure | 35 +- gdb/configure.ac | 11 + include/ctf-backtrace-api.h | 57 + include/ctf-frame-api.h | 213 + include/ctf-frame.h | 257 + include/elf/common.h | 1 + include/elf/internal.h | 1 + ld/ld.texi | 4 +- ld/scripttempl/elf.sc | 2 + libctfframe/Makefile.am | 41 + libctfframe/Makefile.in | 966 ++ libctfframe/aclocal.m4 | 1241 +++ libctfframe/config.h.in | 144 + libctfframe/configure | 15118 +++++++++++++++++++++++++++ libctfframe/configure.ac | 75 + libctfframe/ctf-backtrace-err.c | 46 + libctfframe/ctf-backtrace.c | 617 ++ libctfframe/ctf-frame-dump.c | 162 + libctfframe/ctf-frame-error.c | 49 + libctfframe/ctf-frame-impl.h | 55 + libctfframe/ctf-frame.c | 1515 +++ libctfframe/ttest.c | 78 + sim/common/Make-common.in | 7 +- 62 files changed, 24914 insertions(+), 47 deletions(-) create mode 100644 bfd/elf-ctf-frame.c create mode 100644 binutils/doc/ctfframe.options.texi create mode 100644 gas/ctffreopt.c create mode 100644 gas/gen-ctf-frame.c create mode 100644 gas/gen-ctf-frame.h create mode 100644 include/ctf-backtrace-api.h create mode 100644 include/ctf-frame-api.h create mode 100644 include/ctf-frame.h create mode 100644 libctfframe/Makefile.am create mode 100644 libctfframe/Makefile.in create mode 100644 libctfframe/aclocal.m4 create mode 100644 libctfframe/config.h.in create mode 100755 libctfframe/configure create mode 100644 libctfframe/configure.ac create mode 100644 libctfframe/ctf-backtrace-err.c create mode 100644 libctfframe/ctf-backtrace.c create mode 100644 libctfframe/ctf-frame-dump.c create mode 100644 libctfframe/ctf-frame-error.c create mode 100644 libctfframe/ctf-frame-impl.h create mode 100644 libctfframe/ctf-frame.c create mode 100644 libctfframe/ttest.c -- 2.31.1