From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69317 invoked by alias); 23 Sep 2019 21:11:54 -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 69264 invoked by uid 89); 23 Sep 2019 21:11:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.3 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=pm, UD:p.m, corruption, p.m X-HELO: aserp2120.oracle.com Received: from aserp2120.oracle.com (HELO aserp2120.oracle.com) (141.146.126.78) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Sep 2019 21:11:52 +0000 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8NKx7Er018844; Mon, 23 Sep 2019 21:11:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=+AQBSYnVT95R5gHlXkyT0qgfk4q+miN1KvqdFBjg2og=; b=kvCxK2Og4dN7rpUYuFPM+AJ8/Z1VOh6jAujCFyLwMrBfPIBnhhYt9L7TPaCe+AsDuoIP Ewi/1CdtQ1DZO24zmeuD0JFj3GJUMG3c6YFL+kpTtNHKrVhZswox8doXaN4w4IX3j4PS O+d+U+GG3EL8WPyyla6BNvbJFDwIrYxHRzk+rB1NX6btH3KVeGc03VUftz1TQOpixcse 0NDfqEuekDA7CvfIM/Hq8amCeYaIo4gGWdMalH9tFyzH5Yv8Vaz9FYfGgtUnTzhoGm9Y kH3+vu0As+S9n/cRP09YCZY6Aiidu62HBYhkwREEW6PGePH1FRC7QgQsLic68e1iEXZQ 5w== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2v5btpsnup-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Sep 2019 21:11:48 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8NKwcDr093263; Mon, 23 Sep 2019 21:11:47 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 2v6yvhhq9r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Sep 2019 21:11:47 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x8NLBhWs007237; Mon, 23 Sep 2019 21:11:44 GMT Received: from [10.132.96.98] (/10.132.96.98) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Sep 2019 14:11:43 -0700 Subject: Re: [PATCH v2] gdb: CTF support To: Simon Marchi , gdb-patches@sourceware.org References: <1564530195-27659-1-git-send-email-weimin.pan@oracle.com> From: Weimin Pan Message-ID: <206312d5-cc32-15f0-dd20-25f8d7dbb369@oracle.com> Date: Mon, 23 Sep 2019 21:11:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-09/txt/msg00452.txt.bz2 Hi Simon, On 9/21/2019 3:21 PM, Simon Marchi wrote: > Hi Weimin, > > I'd like to give this a try and review this, but I hit a wall. I compiled > gcc with this patch series (v5) applied: > > https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00457.html > > I am able to compile a simple .c file with -gt, and the resulting > binary contains a .ctf section. But when loading the file in GDB, > I get this: > > (gdb) file a.out > Reading symbols from a.out... > ctf_bfdopen failed on /home/simark/build/binutils-gdb/gdb/a.out - File data structure corruption detected > > The error occurs in ctf_bufopen, at line 1294: > > 1294 if (hp.cth_lbloff > hp.cth_objtoff > 1295 || hp.cth_objtoff > hp.cth_funcoff > 1296 || hp.cth_funcoff > hp.cth_typeoff > 1297 || hp.cth_funcoff > hp.cth_varoff > 1298 || hp.cth_varoff > hp.cth_typeoff || hp.cth_typeoff > hp.cth_stroff) > 1299 return (ctf_set_open_errno (errp, ECTF_CORRUPT)); > > `hp` is: > > $10 = { > cth_preamble = { > ctp_magic = 57330, > ctp_version = 4 '\004', > ctp_flags = 0 '\000' > }, > cth_parlabel = 0, > cth_parname = 0, > cth_lbloff = 10, > cth_objtoff = 0, > cth_funcoff = 0, > cth_varoff = 0, > cth_typeoff = 12, > cth_stroff = 12, > cth_strlen = 16 > } > > The program I compiled is: > > int main() { > return 2; > } > > compiled with: > > /data/scratch/gcc-install/bin/gcc test.c -gt -O0 Looks like you're using the latest gcc patch with current upstream binutils. Unfortunately, these two are not compatible since the latter lacks two newer header fields and the ability to transparently upgrade the ctf header. The same problem can be reproduced with "readelf" from binutils master: % readelf --ctf=".ctf" a.out readelf: Error: CTF open failure: File data structure corruption detected Please try applying the linker patch series that NicK posted on Sep 6 to binutils, under the name of "CTF linking support", as mentioned in the gcc patch sited above: NickA recently posted a changeset to the binutils mailing list that adds initial support for linking CTF sections. Please see https://sourceware.org/ml/binutils/2019-09/msg00045.html ( This current GCC  patch set has the ctf.h in sync with the above-mentioned    binutils patch set. ) which should fix this problem. > On 2019-07-30 7:43 p.m., Weimin Pan wrote: >> [Changes from v1: >> - Add libctf dependencies in Makefile.def and Makefile.in. >> - Use type-safe registry API for per-objfile data ctf_tid_key. >> - Replace buildsym-legacy.h with buildsym.h. >> - Use xcalloc/xfree to allocate hash tables. >> - Use get_global_symbols() instead of get_file_symbols() to add symbols. >> - Rename gdb/ctf.h to /gdb/tracectf.h.] > Could you please rename ctf.c to tracectf.c as well? It's much easier when the > corresponding .c and .h are named the same way. I'd also like if you did that > renaming it a separate, preparatory patch, just to keep each patch focused. Good idea (there seemed to be some confusion about "ctf.c" at GNU Tools Cauldron 2019.) Will do it separately. Thank you very much for taking the time. Weimin > > Simon