From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 909013858002 for ; Mon, 29 Mar 2021 17:13:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 909013858002 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 12THDYgT022792 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Mar 2021 13:13:39 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12THDYgT022792 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 836561E590; Mon, 29 Mar 2021 13:13:34 -0400 (EDT) Subject: Re: Need help with understanding truncated and corrupted backtraces To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <83lfandydz.fsf@gnu.org> <6c4e73b8-6c0d-4c9c-a4ae-8de85976fde1@polymtl.ca> <83zgyrilyd.fsf@gnu.org> <340a8bb9-87f8-1b37-7ba9-8d497535642e@polymtl.ca> <83eefymlnn.fsf@gnu.org> <6a181a11-80b8-677a-927d-e1a6addf629d@polymtl.ca> <83wntqknx3.fsf@gnu.org> <83o8f2km37.fsf@gnu.org> <7c6616ea-e62e-434d-ec67-4734703860cb@polymtl.ca> <83im59lx22.fsf@gnu.org> From: Simon Marchi Message-ID: <188fbc33-89c3-e046-6dd1-f220ed8b78ad@polymtl.ca> Date: Mon, 29 Mar 2021 13:13:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <83im59lx22.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 29 Mar 2021 17:13:34 +0000 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 17:13:51 -0000 On 2021-03-29 12:55 p.m., Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Simon Marchi >> Date: Mon, 29 Mar 2021 11:39:41 -0400 >> >> On 2021-03-29 11:37 a.m., Eli Zaretskii wrote: >>>> Cc: gdb-patches@sourceware.org >>>> From: Simon Marchi >>>> Date: Mon, 29 Mar 2021 11:32:14 -0400 >>>> >>>> So, the JIT code produces code and a stack layout that GDB's prologue >>>> analyzer doesn't understand. As mentioned previously, you have two >>>> options: looking into having dwarf info produced for the jit-ed code, or >>>> tweaking GDB's prologue analyzer to make it understand your code and >>>> stack. >>> >>> Thanks. >>> >>> The JIT code was produced by libgccjit, so is it reasonable that its >>> prologue is different from the one produced by GCC? >> >> Maybe, I have no idea as I have never used it. > > I'm out of my depth here, but just FTR, I took one function whose name > is shown as "??" and used "x/10i" to display instructions back from > $pc until I saw RET. I presume that's where this anonymous function > starts. Here's what I see immediately following that RET instruction: > > 0x996e6b2: lea 0x0(%esi,%eiz,1),%esi > 0x996e6b9: lea 0x0(%esi,%eiz,1),%esi > 0x996e6c0: push %ebp > 0x996e6c1: mov %esp,%ebp > 0x996e6c3: push %edi > 0x996e6c4: push %esi > 0x996e6c5: push %ebx > 0x996e6c6: sub $0x8c,%esp > > Which AFAIK is the "normal" prologue (perhaps modulo the 2 lea > instructions)? "push %ebp" and "mov %esp, %ebp" is the start of a typical prologue. So the above looks quite typical. The lea instructions are just NOPs for alignment: https://stackoverflow.com/questions/2553517/what-is-register-eiz When GDB attempts to analyze the prologue of the function of frame #3 (from your initial example), then it must have some way of finding the start of the function that PC "0x099485bb" is in. We want it to find the PC of the "push %ebp" instruction, if it goes back too far and finds the PC of one of those lea instructions, then it won't look at the right instructions when analyzing the prologue. It would be good to check how it does that, and if it gets that right. I think you would need to inspect the beginning of i386_frame_cache_1, where it does: cache->pc = get_frame_func (this_frame); That PC should point to "push %ebp", ideally. It is passed to i386_analyze_prologue a few lines below, in i386_frame_cache_1: if (cache->pc != 0) i386_analyze_prologue (gdbarch, cache->pc, get_frame_pc (this_frame), cache); Simon