From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69579 invoked by alias); 22 Jan 2016 06:47:00 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 69551 invoked by uid 89); 22 Jan 2016 06:46:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=particulars X-HELO: mail-lb0-f174.google.com Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com) (209.85.217.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 22 Jan 2016 06:46:58 +0000 Received: by mail-lb0-f174.google.com with SMTP id oh2so35810238lbb.3 for ; Thu, 21 Jan 2016 22:46:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X8/Ox8K4y+vYiCmLjFmRbv06JLr0VUf7FKXlsn9Yd7E=; b=MZjErcs5eAuUmtgdPnsn1k3IxhgqEkkpv7FvB8LAyv/3R3zuBshuRm1nbGdIQx9XXe EliLHqdQGQugAmXE3jZ31i6ETp93NF1INYyyvejEGxyqshjLNRFRFtG04ftLoXt2HvM6 hxJtLySb9nOBJBqEqEvsam/n2RObF0HCKyAv3RLv4xuXXhaje//MfJnwIdA1629rTbsi VSEfZURTAvBh5WLb8Me1mvzBqYJAWd9f7kIqTaBBQdaClkyxJytCgL2OtjalDYnGedYj rrc32ySMwlYxBY2QxNu3dxPsCAJpM/LX+jMB1UIrExptIz2Ta4Ujt4Iq5KwyVnFWRBjE vyiA== X-Gm-Message-State: AG10YOSIeqks3GLjmPI0r4pobhrx0dpQJlpKG1/MQl3ZNL5JlDKp53RWulxzfKGQKkcWjrtDLCmhF7vfnQ4bIA== MIME-Version: 1.0 X-Received: by 10.112.209.2 with SMTP id mi2mr436163lbc.139.1453445214766; Thu, 21 Jan 2016 22:46:54 -0800 (PST) Received: by 10.112.43.175 with HTTP; Thu, 21 Jan 2016 22:46:54 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Jan 2016 06:47:00 -0000 Message-ID: Subject: Re: x64 machine code and stack frames From: Dov Grobgeld To: Matt Rice Cc: GDB Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00047.txt.bz2 Thanks. Indeed it sounds like the right direction. I have to figure out how it works in a mixed environment with both static DWARF based code as well as dynamically allocated code. On Fri, Jan 22, 2016 at 4:27 AM, Matt Rice wrote: > > > On Thu, Jan 21, 2016 at 11:45 AM, Dov Grobgeld > wrote: >> >> Hello, >> >> I've inherited some clever x64 machine code for linux that creates an >> machine code wrapper around a c-function call. I guess that in higher >> language terms the code might be called a decorator or a closure. The >> code is functioning well, but with the unfortunate artifact that when >> the wrapper is called, it gobbles the stack trace in gdb. >> >> From what I have learned from the net gdb uses >> https://en.wikipedia.org/wiki/DWARF as a guide for separating the >> stack frames in the stack. This works well for static code, but >> obviously code generated and called at run time isn't registered in >> the DWARF framework. >> >> My question is if there is any way to rescue the stack trace in this >> situation? > > > While i haven't really used it before & can't comment on the particulars, > It sounds like you should be using the jit interface to make gdb aware of > the symbols generated at runtime. > > https://sourceware.org/gdb/onlinedocs/gdb/JIT-Interface.html