From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9238 invoked by alias); 21 Sep 2019 22:21:45 -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 9224 invoked by uid 89); 21 Sep 2019 22:21:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=Pan, pan, focused X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 21 Sep 2019 22:21:43 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 3150B1E593; Sat, 21 Sep 2019 18:21:40 -0400 (EDT) Subject: Re: [PATCH v2] gdb: CTF support To: Weimin Pan , gdb-patches@sourceware.org References: <1564530195-27659-1-git-send-email-weimin.pan@oracle.com> From: Simon Marchi Message-ID: Date: Sat, 21 Sep 2019 22:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <1564530195-27659-1-git-send-email-weimin.pan@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-09/txt/msg00434.txt.bz2 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 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. Simon