Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Weimin Pan <weimin.pan@oracle.com>
To: Simon Marchi <simark@simark.ca>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2] gdb: CTF support
Date: Wed, 25 Sep 2019 00:22:00 -0000	[thread overview]
Message-ID: <b10e1bb6-e4ed-d795-ef9e-86b377d42eb3@oracle.com> (raw)
In-Reply-To: <99d30cd3-4c97-2455-b9f1-f44290f136d8@simark.ca>


On 9/23/2019 8:10 PM, Simon Marchi wrote:
> On 2019-09-23 5:11 p.m., Weimin Pan wrote:
>> 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.
> Oh ok thanks.  Do you happen to know if that binutils patchset is available on a
> git branch somewhere?  I'd like to avoid applying these 33 patches by hand.  If
> you have a combined branch with the binutils and gdb changes together, it would
> be even better :).
Hi Simon,

I have created a combined branch with changes in both binutils and gdb
on our server and tested it a bit. Trying to send it upstream doesn't work:

% git remote -v
origin  git://ca-tools4.us.oracle.com/binutils-gdb.git (fetch)
origin  git://ca-tools4.us.oracle.com/binutils-gdb.git (push)
upstream        ssh://sourceware.org/git/binutils-gdb.git (fetch)
upstream        ssh://sourceware.org/git/binutils-gdb.git (push)

% git push upstream oracle/ctf:oracle/ctf
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

%

Weimin

>
> Simon


  reply	other threads:[~2019-09-25  0:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30 23:45 Weimin Pan
2019-09-21 22:21 ` Simon Marchi
2019-09-23 21:11   ` Weimin Pan
2019-09-24  3:10     ` Simon Marchi
2019-09-25  0:22       ` Weimin Pan [this message]
2019-09-25  0:27         ` Simon Marchi
2019-09-25  2:04           ` Wei-min Pan
2019-09-25  2:35             ` Simon Marchi
2019-09-25 21:09               ` Wei-min Pan
2019-09-30  3:06 ` Simon Marchi
2019-10-01  0:37   ` Weimin Pan
2019-10-02  2:47     ` Simon Marchi
2019-10-02 23:10       ` Wei-min Pan
2019-10-03 12:40         ` Simon Marchi
2019-10-03 17:59           ` Wei-min Pan
2019-10-03 18:01             ` Simon Marchi
2019-10-03 18:21               ` Wei-min Pan
2019-10-03 18:31                 ` Simon Marchi
2019-10-03 18:53                   ` Wei-min Pan
2019-10-03 20:33                     ` Wei-min Pan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b10e1bb6-e4ed-d795-ef9e-86b377d42eb3@oracle.com \
    --to=weimin.pan@oracle.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox