From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SwHMEOLzuWjiIhQAWB0awg (envelope-from ) for ; Thu, 04 Sep 2025 16:17:38 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=HrjMqFfv; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 300961E087; Thu, 04 Sep 2025 16:17:38 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 4994B1E047 for ; Thu, 04 Sep 2025 16:17:37 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C5379385841E for ; Thu, 4 Sep 2025 20:17:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C5379385841E Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=HrjMqFfv Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id C81D93858C31 for ; Thu, 4 Sep 2025 20:16:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C81D93858C31 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C81D93858C31 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1757017001; cv=none; b=MZ+oiKAQEEwuOLrUXgw4JBdmJhdlrILuo4FKrIjK/yHkSlzNMoGfXt3TfQGJutaZpqQ4IErQGUikMZa6ZRfqy/S34ajEZ3S0KUcmGP+6T2fVgkcvhmOwWgPGajwVQznhbny8DJmdbNSxK/B+PtkeU1tU8WTfheVMLVE87dvrEpo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1757017001; c=relaxed/simple; bh=fhzLIXaRP1t8XXUow4EwKxLHxqN3hMhlJRewD7WRqDE=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=xEq/8uvqa6ltnXqLku8PRX7PNizEMpXE+nw8WigTtDvGSzAc1oGaCsHHS61cQ2YgDmyKjZspkjYIG/1sx1AVUTideikdg4BV/zYyzCR1FKmZK4kZJkZ4p4RiLW6MGH2sVJjqUqjQJQLTEA5Lwyiq2wUp8dfE3sk6UTrhgRg41QM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C81D93858C31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1757017001; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Kshd7KbQlkMJYxWnOsls7i4EJ697WepGRlXtx+Xm/T8=; b=HrjMqFfvhqkXni9+R6xSWpGKmZHxQ3Jk7Dy+Qj+LIRfkIbpAH8QN6fWNXDHw/Vbunc4OkT fomrIwasSzHgfM2fulEGlF4tVN+jwXhvIhacIEh3KKqQHv7G9BV+BR8qoBtyHhvW0sQpyV GxW2uWypOsIwAA0EiKiUCMflVHxN52Q= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-553-qA1mxJ9lMvCMN36FAFBlGA-1; Thu, 04 Sep 2025 16:16:40 -0400 X-MC-Unique: qA1mxJ9lMvCMN36FAFBlGA-1 X-Mimecast-MFC-AGG-ID: qA1mxJ9lMvCMN36FAFBlGA_1757016999 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3cef6debe96so837424f8f.1 for ; Thu, 04 Sep 2025 13:16:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757016999; x=1757621799; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Kshd7KbQlkMJYxWnOsls7i4EJ697WepGRlXtx+Xm/T8=; b=DkPoagHenfeE3ShVHBhffrMxrUyPujKiLhiWSpKDh9h72qFuX1SbLAu9f05vmSPPjF qBFYVbsv0ucrELjpSsWe7bPS3wvI0MeUFHOh+v4TDLq5nygex34pVcyPJ5GaoMk4XVcW HTFAI3RnFQqS+r24pe1++wYUV7bas3rw//CSDfAs+yCka9VLVMnyL61odzlxOaqolbCI tlu9aFRHOSXOykLoVUk6lDLdAfflrl5QqCzlGsoF5EcI3tdhQJofEpJGH5RfhRyRSVpS T6BklxyCvYQgYkA/0/6EPbM2uhsMDN6dFlMXgwTxxlWiX7DpARynwws+4vWwjXw2RExx NfaA== X-Gm-Message-State: AOJu0YzXteEgoxFwZFJLJSQLPitl22qXwaUrbIjmOA/7BsumuXpVWH8I 5Af8l8oo5dUXZ8KLt7OkHoTKpTkrgnH9hcFJsfvqA59fYZ+YmGOz2oRH2aNcXEU0ir+tDjsY7Uf lk80sFBmxDPAK6kpIiUu+xzPi1QSmQqrsAaaFsiiQpvCH2cdakbtLir/0PnkkV5Lr2WxB187aOE 7L3GFG7a/gWhAtb/nRKwROxKB50WyF3xrEFXH4C/wa0J+ZVII= X-Gm-Gg: ASbGncvmQce4dKnGLmYk4HDObAgkBGmkQXLmJJ3zjapkoYpYH1W0sMbQoQ80qEdza/c Iaet9jV+Drqhd5Okw2laxlQr3yK82STzbVDcGLBXsn8HfirHNb1zgKCl5zfUaCIev+wE/rvONh2 Be5kLJsH+ApXuw+S6k+uVrEGmPzEtk3s3xE2qNSUSyihnlPD5CORjGKNCcRXTWcWIh0mK1hk3Y7 0dAu2h5rTeqpYALpL2BjjlmH9Ne9GAfqqgP9OC83uiYHV5foQkVYIBME3UhJKVRUA79SgjnoO1F Fjvgja1Tq1/Nd/gAY29rWsCJCz+ZNnAqey0= X-Received: by 2002:a5d:5d07:0:b0:3de:e787:5d5e with SMTP id ffacd0b85a97d-3dee78761a6mr6041479f8f.43.1757016998705; Thu, 04 Sep 2025 13:16:38 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG7Nvbx9DEFvjmiDyvoqNRTW31nKPipKKIP1svUtQ3Ni64Lx/jDqdF7tehq0Sh34Fn+5sHr5w== X-Received: by 2002:a5d:5d07:0:b0:3de:e787:5d5e with SMTP id ffacd0b85a97d-3dee78761a6mr6041459f8f.43.1757016998159; Thu, 04 Sep 2025 13:16:38 -0700 (PDT) Received: from localhost ([31.111.84.207]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3deb99d10a0sm7296026f8f.37.2025.09.04.13.16.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Sep 2025 13:16:37 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH] gdb: ensure bp_location::section is set correct to avoid an assert Date: Thu, 4 Sep 2025 21:16:35 +0100 Message-ID: <6ebdf11970be5450d222e5d3af746671136ed57d.1757016971.git.aburgess@redhat.com> X-Mailer: git-send-email 2.47.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: KWhonpQip6nwKMhdpnXEkr1vfYKlg7vga7i9chuGKVY_1757016999 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org While reviewing and testing another patch I set a breakpoint on an gnu ifunc function, then restarted the inferior, and this assert triggered: ../../src/gdb/breakpoint.c:14747: internal-error: breakpoint_free_objfile: Assertion `loc->symtab == nullptr' failed. The backtrace at the time of the assert is: #6 0x00000000005ffee0 in breakpoint_free_objfile (objfile=0x4064b30) at ../../src/gdb/breakpoint.c:14747 #7 0x0000000000c33ff2 in objfile::~objfile (this=0x4064b30, __in_chrg=) at ../../src/gdb/objfiles.c:478 #8 0x0000000000c38da6 in std::default_delete::operator() (this=0x7ffc1a49d538, __ptr=0x4064b30) at /usr/include/c++/9/bits/unique_ptr.h:81 #9 0x0000000000c3782a in std::unique_ptr >::~unique_ptr (this=0x7ffc1a49d538, __in_chrg=) at /usr/include/c++/9/bits/unique_ptr.h:292 #10 0x0000000000caf1bd in owning_intrusive_list >::erase (this=0x3790d68, i=...) at ../../src/gdb/../gdbsupport/owning_intrusive_list.h:111 #11 0x0000000000cacd0c in program_space::remove_objfile (this=0x3790c80, objfile=0x4064b30) at ../../src/gdb/progspace.c:192 #12 0x0000000000c33e1c in objfile::unlink (this=0x4064b30) at ../../src/gdb/objfiles.c:408 #13 0x0000000000c34fb9 in objfile_purge_solibs (pspace=0x3790c80) at ../../src/gdb/objfiles.c:729 #14 0x0000000000edf6f7 in no_shared_libraries (pspace=0x3790c80) at ../../src/gdb/solib.c:1359 #15 0x0000000000fb3f6c in target_pre_inferior () at ../../src/gdb/target.c:2466 #16 0x0000000000a724d7 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:390 #17 0x0000000000a72a97 in run_command (args=0x0, from_tty=0) at ../../src/gdb/infcmd.c:514 #18 0x00000000006bbb3d in do_simple_func (args=0x0, from_tty=0, c=0x39124b0) at ../../src/gdb/cli/cli-decode.c:95 #19 0x00000000006c1021 in cmd_func (cmd=0x39124b0, args=0x0, from_tty=0) at ../../src/gdb/cli/cli-decode.c:2827 The function breakpoint_free_objfile is being called when an objfile representing a shared library is being unloaded ahead of the inferior being restarted, the function is trying to remove references to anything that could itself reference the objfile that is being deleted. The assert is making the claim that, for a bp_location, which has a single address, the objfile of the symtab associated with the location will be the same as the objfile associated with the section of the location. This seems reasonable to me now, as it did when I added the assert in commit: commit 5066f3680667ec0f2d1745847a2372d85973a1e7 Date: Mon Nov 11 21:45:17 2024 +0000 gdb: do better in breakpoint_free_objfile The bp_location::section is maintained, according to the comments in breakpoint.h, to aid overlay debugging (is that even used any more), and looking at the code, this does appear to be the case. The problem in the above case arises when we are dealing with an ifunc function. What happens is that we end up with a section from one objfile, but a symtab from a different objfile. This problem originates from minsym_found (in linespec.c). The user asked for 'break gnu_ifunc' where 'gnu_ifunc' is an ifunc function. What this means is that gnu_ifunc is actually a resolver function that returns the address of the actual function to use. In this particular test case, the resolver function is in a shared library, and the actual function to use is in the main executable. So, when GDB looks for 'gnu_ifunc' is finds the minimal_symbol with that name, and spots that this has type mst_text_gnu_ifunc. GDB then uses this to figure out the actual address of the function that will be run. GDB then creates the symtab_and_line using the _real_ address and the symtab in which that address lies, in our case this will all be related to the main executable objfile. But, finally, in minsym_found, GDB fills in the symtab_and_line's section field, and this is done using the section containing the original minimal_symbol, which is from the shared library objfile. The minimal symbol and section are then use to initialise the bp_location object, and this is how we end up in, what I think, is an unexpected state. So what to do about this? The symtab_and_line::msymbol field is _only_ set within minsym_found, and is then _only_ used to initialise the bp_location::msymbol field. The bp_location::msymbol field is _only_ used in the function set_breakpoint_location_function, and we only really care about the msymbol type, we check to see if it's an ifunc symbol or not. This allows us to set the name of the function correctly. The bp_location::section is used, as far as I can tell, extensively for overlay handling. It would seem to me, that this section should be the section containing the actual breakpoint address. If the question we're asking is, is this breakpoint mapped in or not? Then surely we need to ask about the section holding the breakpoint's address, and not the section holding some other code (e.g. the resolver function). In fact, in a memory constrained environment, you'd expect the resolver functions to get mapped out pretty early on, but while the actual functions might still be mapped in. Finally, symtab_and_line::section. This is mostly set using calls to find_pc_overlay. The minsym_found function is one of the few places where we do things differently. In the places where the section is used, it is (almost?) always used in conjunction with the symtab_and_line::pc to lookup information, e.g. calls to block_for_pc_sect, or find_pc_sect_containing_function. In all these cases, it appears to me that the assumption is that the section will be the section that contains the address. So, where does this leave us? I think what we need to do is update minsym_found to just use find_pc_overlay, which is how the symtab_and_line::section is set in most other cases. What this actually means in practise is that the section field will be set to NULL (see find_pc_overlay in symfile.c). But given that this is how the section is computed in most other cases, I don't see why it should be especially problematic for this case. In reality, I think this just means that the section is calculated via a call to find_pc_section when it's needed, as an example, see lookup_minimal_symbol_by_pc_section (minsyms.c). I do wonder if we should be doing better when creating the symtab_and_line, and insist that the section be calculated correctly at that point, but I really don't want to open that can of worms right now, so I think just changing minsym_found to "do it just like everyone else" should be good enough. I've extended the existing ifunc test to expose this issue, the updated test fails without this patch, and passes with. --- gdb/linespec.c | 7 ++++++- gdb/testsuite/gdb.base/gnu-ifunc.exp | 5 +++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/gdb/linespec.c b/gdb/linespec.c index cefee026d92..e634bf22f3c 100644 --- a/gdb/linespec.c +++ b/gdb/linespec.c @@ -4113,7 +4113,12 @@ minsym_found (struct linespec_state *self, struct objfile *objfile, sal.pspace = current_program_space; } - sal.section = msymbol->obj_section (objfile); + /* Don't use the section from the msymbol, the code above might have + adjusted FUNC_ADDR, in which case the msymbol's section might not be + the section containing FUNC_ADDR. It might not even be in the same + objfile. As the section is primarily to assist with overlay + debugging, it should reflect the SAL's pc value. */ + sal.section = find_pc_overlay (sal.pc); if (self->maybe_add_address (objfile->pspace (), sal.pc)) add_sal_to_sals (self, result, &sal, msymbol->natural_name (), false); diff --git a/gdb/testsuite/gdb.base/gnu-ifunc.exp b/gdb/testsuite/gdb.base/gnu-ifunc.exp index c7afbe5fc59..20a09973425 100644 --- a/gdb/testsuite/gdb.base/gnu-ifunc.exp +++ b/gdb/testsuite/gdb.base/gnu-ifunc.exp @@ -185,6 +185,11 @@ proc_with_prefix set-break {resolver_attr resolver_debug final_debug} { # other two locations. gdb_test "info breakpoints" "$location\r\n.*$location\r\n$location" } + + # At one point a bug existed such that GDB would trigger an assert + # while restarting the inferior with ifunc breakpoints set. + gdb_run_cmd + gdb_test "" "Breakpoint $::decimal,.*final \\(\[^\r\n\]*\\).*" "restart, run until breakpoint" } # Misc GNU ifunc tests. For the description of RESOLVER_ATTR, base-commit: 7bdcd19cc6d8137ecdca83571946d6ffb7b4be26 -- 2.47.1