From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id A7E493858D20 for ; Mon, 11 Mar 2024 19:50:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A7E493858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A7E493858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710186640; cv=none; b=j19mB5x2LrpCrByHaA6cOBn3yYnxCtzl0zP+p7IjqO8AtAK6CtW3E6QdlSZu88Y4gj9cLFTI2l+Zl6YifArICkYoEUHW4ZyJfxCxV+tEoeF8L/VQ/p2XyWfpiU3xhVvfMn2rGrxhb8TGaU0l5X2AkKRMuFi95+35HCF4uBh0LbI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710186640; c=relaxed/simple; bh=lHpQbUm182WSGjQ0vdCS/WBfK2kDAnbPvfSDelMv/f8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=EPbcYMdMLtBENq1NIs+cI49j5i99yfOu5ziuybVypPdfLstTKgwqyVD/8NiAarhfZ+2caYmK1e2Y+40BA7g0wiaJEUTewjCBQH4mNNcZHgq7tMaEBJ9rkOc1cUKCfZVjKbsc+0AMPn+M5Fd5MHlYFmoCZeo9YJRgqzPUrx4aSP8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1710186638; bh=lHpQbUm182WSGjQ0vdCS/WBfK2kDAnbPvfSDelMv/f8=; h=Date:Subject:To:References:From:In-Reply-To:From; b=ci++XkBd8CW66I58JiwI09Vc8NxSoCBZSHDSCx64fSGohDbFQK2uWndN/Aw3HlA3K jTGZky5buXxdUSWG87fIM5UUF7HjxrFewCCDpgzD2CJoM3gXgdtUJVasCbxqvZRaio lyJsNiu0Psa51TsAJJi49cFQry/V7jyi4cQUFgV0= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 598851E0AC; Mon, 11 Mar 2024 15:50:38 -0400 (EDT) Message-ID: <06c7a0d1-6ba7-440a-a21a-616ed05cb5b0@simark.ca> Date: Mon, 11 Mar 2024 15:50:38 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: GDB 13.2: breakpoint at wrong line after unrelated change Content-Language: fr To: psmith@gnu.org, gdb@sourceware.org References: <7c064cc544bfe453a250ca58b4d5ebd97919178d.camel@gnu.org> <4c3f986c-a562-4506-b382-c754678abcff@simark.ca> <7fcf12fbd4a106af488168d0e740e0d8ca9b3022.camel@gnu.org> From: Simon Marchi In-Reply-To: <7fcf12fbd4a106af488168d0e740e0d8ca9b3022.camel@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 3/11/24 15:38, Paul Smith via Gdb wrote: > On Mon, 2024-03-11 at 15:14 -0400, Simon Marchi wrote: >>> I have noticed that if I only include the templated function >>> definition but don't call it, then the problem doesn't happen. >> >> When you say that, does it mean that you just define the templated >> function, or do you manually instantiate it? In other words, does it >> cause any code to be generated? > > If I just define the templated function I don't see the issue. If I > invoke the templated function, I get the problem. > > FYI I'm switching to the fmt library (if you're familiar with that) Yes, I love it, we should use it in GDB :). > and > the templated function invokes it; it's something like this: > > void criticalErrorV(fmt::string_view fmt, const char *file, int line, > fmt::format_args args); > > template > void criticalError(fmt::format_string fmt, > const char* file, int line, Args &&...args) > { > criticalErrorV(fmt, file, line, fmt::make_format_args(args...)); > } > > If I never call criticalError() then it works fine (or in my previous > implementation, which used printf-style calls with stdarg, it worked > fine as well). If you never call it, if never generates code, so it kinda make sense that it doesn't change anything. > If I have some invocation of criticalError() somewhere in the > translation unit, I get this problem. I haven't checked moving it > around to see if it needs to be invoked before/after the "problem" > method in the TU to get this behavior. > >> I don't really have an idea of what's happening, but you could try >> showing what the "disas" command shows after hitting the breakpoint >> in both cases (the `=>` should show where you are stopped, so where >> the breakpoint was set). > > Good idea; here's what I get for the correct behavior: > > 0x000000000053209c <+0>: push %rbp > 0x000000000053209d <+1>: mov %rsp,%rbp > 0x00000000005320a0 <+4>: lea -0x10(%rsp),%rsp > 0x00000000005320a5 <+9>: mov %rdi,-0x8(%rbp) > 0x00000000005320a9 <+13>: mov %rsi,-0x10(%rbp) > => 0x00000000005320ad <+17>: mov -0x10(%rbp),%rax > 0x00000000005320b1 <+21>: mov %rax,%rsi > 0x00000000005320b4 <+24>: lea 0x17e9a9(%rip),%rax # 0x6b0a64 > 0x00000000005320bb <+31>: mov %rax,%rdi > 0x00000000005320be <+34>: mov $0x0,%eax > 0x00000000005320c3 <+39>: call 0x52bc00 > 0x00000000005320c8 <+44>: nop > 0x00000000005320c9 <+45>: mov %rbp,%rsp > 0x00000000005320cc <+48>: pop %rbp > 0x00000000005320cd <+49>: ret > > Here's what I get for the incorrect behavior: > > => 0x00000000005320ee <+0>: push %rbp > 0x00000000005320ef <+1>: mov %rsp,%rbp > 0x00000000005320f2 <+4>: lea -0x10(%rsp),%rsp > 0x00000000005320f7 <+9>: mov %rdi,-0x8(%rbp) > 0x00000000005320fb <+13>: mov %rsi,-0x10(%rbp) > 0x00000000005320ff <+17>: mov -0x10(%rbp),%rax > 0x0000000000532103 <+21>: mov %rax,%rsi > 0x0000000000532106 <+24>: lea 0x17e9d6(%rip),%rax # 0x6b0ae3 > 0x000000000053210d <+31>: mov %rax,%rdi > 0x0000000000532110 <+34>: mov $0x0,%eax > 0x0000000000532115 <+39>: call 0x52bc00 > 0x000000000053211a <+44>: nop > 0x000000000053211b <+45>: mov %rbp,%rsp > 0x000000000053211e <+48>: pop %rbp > 0x000000000053211f <+49>: ret > > It seems to have given up and just picked the first instruction :) > > Here's the compile line args (removed extraneous stuff like warnings > and preprocessor options): > > g++ -std=gnu++20 -ggdb3 -fPIC -march=haswell -mtune=intel \ > -fno-omit-frame-pointer -O0 -pthread \ > -o TestClass.o -c TestClass.cpp Ok, so clearly GDB failed to analyze the prologue. Which is weird because the two functions are identical (modulo the addresses). To get to the bottom of this, you (or someone else) would need to debug GDB itself. If you want to do this, I would start at function skip_prologue_using_sal, in symtab.c. Off hand, I don't think we have a debug switch to enable logging for prologue skipping. It would be useful to have some here, as we would be able to compare the logging shown in both cases. When you have DWARF debug info (which is your case), prologue skipping is done using the DWARF line tables. You could try to extract the line tables for both versions of the function and see what's different. But that would probably only be useful if you're debugging GDB already. Simon