From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UZm4Ie2+bGpW0jcAWB0awg (envelope-from ) for ; Fri, 31 Jul 2026 11:27:41 -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=IMNkexSX; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7BCC91E09E; Fri, 31 Jul 2026 11:27:41 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 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_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (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 481261E099 for ; Fri, 31 Jul 2026 11:27:40 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D8F0C4B1A2BA for ; Fri, 31 Jul 2026 15:27:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D8F0C4B1A2BA 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=IMNkexSX Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id C011B4BA2E1A for ; Fri, 31 Jul 2026 15:27:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C011B4BA2E1A 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 C011B4BA2E1A Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1785511632; cv=none; b=H6vrvLl2ZpO9t9yuHcKCQkwl6GrfWobKuq4/Ger9f4jeT4h4Kfd/Vbl4p0x9myT6rjagyxiAdYy6kUcjiurVoQcNQSrqTUHx+M/wM02wiBiz0TMqUrg9O3jamAXosJOhrt0q+LgQhG9mZjg6CNXR3E9aowCZ1bVN7+Fe4t5tnCo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1785511632; c=relaxed/simple; bh=ZfHHq5GXCwm5GyOtN6K9WnB7TtIZx0nR1XPGY3m//aA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=kbZwJgmJXgDF/36JQAaYDe9OjBh7lQZReSQNXQtXkraJOcpT0ezT9qob3uJ8jOBrGLxapArsRtoT2X4w2BS23n2fQ7KRLo/nJkx7bG+F4ZDwEgxt8Hs31F3bvK6WYk5t+BIuJhImCDR/nVSBOrayaMNKUfAKqN9FLQ3jjLBBhzc= ARC-Authentication-Results: i=1; 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=IMNkexSX DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C011B4BA2E1A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785511632; 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: in-reply-to:in-reply-to:references:references; bh=SG6EjBvxyLYjbQipZoDCC+igCONphbkDKNVNITxWeGo=; b=IMNkexSXNQsnFKbeAG/pqMorczRwtcuLYHMl05IpPsImuwvetoqTVmU7FhEOonQLnz9UD2 N8KW1l3jJqgG+9zj34Vl/XP7gITx6/e2+n94NxaBDpmQog6zc8NF1iNS886LxMpOl6HkyS e2FET/PvMJcxsmNopsIEjm0gnKibfkg= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-630-PunC5goTPXmtEau8fDd3PA-1; Fri, 31 Jul 2026 11:27:09 -0400 X-MC-Unique: PunC5goTPXmtEau8fDd3PA-1 X-Mimecast-MFC-AGG-ID: PunC5goTPXmtEau8fDd3PA_1785511628 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-47f835ac1aeso953026f8f.3 for ; Fri, 31 Jul 2026 08:27:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785511628; x=1786116428; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=SG6EjBvxyLYjbQipZoDCC+igCONphbkDKNVNITxWeGo=; b=AV/WpXmGrZbZlV3cHY2zICLUgm2cPrPCg6jkurpyQjkyOdnDV8CCpUEFzLxJLgpzST yx7FGe9BZP5jLLXrJkEZwA/MAUHMlyHnGIuIeMjjq95JjqdNuD7YShR4zXpRpyvdNTie D65T1QAnpfy07mv+NT28oSJ4q6+ogvQPe/4SNtKEzWtikkXhTCCic79aTeg5xKNLmvNV 35LE5hL4hxtkpjXcv4PcznOMjzAINrPmlAKHe4cOriqgwUnAr5Ve2ve8jBmhPyi8IYL1 rU8Xd8/pLGnLUIrtTIlezKVwvFoUp7p0zeVr1+Sx4TdDCgE3vcTJWcsEhMkMEf7KlIgQ oxxw== X-Forwarded-Encrypted: i=1; AHgh+Rp6d9LukuOnLU/AdaJpv9REcVJP/YeLMvJF9C6xiDxTmJiHunhWLAZ1RDuWY43K/NpOgvgMFHxAuaFgiQ==@sourceware.org X-Gm-Message-State: AOJu0YyyHzshCbSig5TQM/9GvJf7T2JPQnQFuy1DZetw04Mv3BDXQVcn boy3LpCnnuvX3HkDR1UY0YCw7wt0mbbfhOcGeErvTFX/3dHvDVUPMFYxrH0sShwGmRa2mJRVs8r MZjsKCJbWBSQPEdob40m+/DUc1e+9oa9wtiBoB2ccMb9ndC3vBk4lqgTnxjk6/Yc= X-Gm-Gg: AR+sD109VJpXyClnhf3ZOjW1HOnoX7Ux6AgpyNvQwlVfP2imfkpIRRHNx3OgvnNw1ok ZqCqxfzbWp6AmDhmdALtZSP3JuCFdqXMQkFlIQiGazO4dYvhZxjH6l35LdCaUGeZdeEak0PXMwK 6zs6nJNsZypMdJmMsoDZhsagpUPPa1JSSbYZPW3wtG3XbDLcJ06wlo2ETs1ST30XgCP4YiqTqYn g9XjiEiAsg+xzM+dUvIl2EP7QnYCpMi8b7mO91yFupJqASQZlLrLLOU1sM3xC9rZnT6s4jULkkT Tp1HYQBez2rb0MZ9lSZqtuSgVf3pnSBl4DrG3Z9ZiHXuWIuieF5XBn2jVGIlBKvd4QdfLweCYrv xNXYnVJm87MyBi9MN X-Received: by 2002:a05:6000:4287:b0:47f:9751:cb3d with SMTP id ffacd0b85a97d-47fd72c74f5mr172551f8f.8.1785511627836; Fri, 31 Jul 2026 08:27:07 -0700 (PDT) X-Received: by 2002:a05:6000:4287:b0:47f:9751:cb3d with SMTP id ffacd0b85a97d-47fd72c74f5mr172469f8f.8.1785511627229; Fri, 31 Jul 2026 08:27:07 -0700 (PDT) Received: from localhost (92.6.93.209.dyn.plus.net. [209.93.6.92]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd458bf7csm6016423f8f.32.2026.07.31.08.27.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 08:27:06 -0700 (PDT) From: Andrew Burgess To: Craig Blackmore , gdb-patches@sourceware.org Cc: Craig Blackmore , Simon Cook Subject: Re: [PATCH] Add missing null pointer check in get_sal_arch In-Reply-To: <87ik5vmdsi.fsf@redhat.com> References: <20260729150617.3502554-1-craig.blackmore@embecosm.com> <87ik5vmdsi.fsf@redhat.com> Date: Fri, 31 Jul 2026 16:27:06 +0100 Message-ID: <87fr0zmb79.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: OMGkzX-BsDazT5NNYOsaaUrCoMOwYnF-jCs616yVcdU_1785511628 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Andrew Burgess writes: > Craig Blackmore writes: > >> This fixes a GDB crash when trying to set a breakpoint on a function in >> an ELF where there is both no .text section and the first section within >> the ELF is not allocatable. > > This tells us WHAT happened, but not WHY. We understand the input as > you gave a description of the ELF, and you explained the end result, a > crash. But it would be really useful if you could fill in the middle > bit. Why does the objfile end up as NULL? > > When a fix is "add a NULL pointer check" my immediate question is: > should the pointer even be NULL? Maybe there's a better fix elsewhere > in GDB which prevents the pointer from ever becoming NULL. The goal of > the "middle bit" that I asked for above is to convince the reviewers > that NULL is a valid possibility and that a NULL check should be added. > > This commit from April seems like it might be in a similar area of GDB: > > commit cd289df068e39683576f95907b5dd06ae3e4e254 > Date: Wed Apr 15 10:43:31 2026 +0100 > > gdb: don't use .text as default entry point section > > and might be worth a read. I looked at this a bit more and `init_objfile_sect_indices` ends with this code: for (i = 0; i < objfile->section_offsets.size (); i++) { if (objfile->section_offsets[i] != 0) { break; } } if (i == objfile->section_offsets.size ()) { if (objfile->sect_index_text == -1) objfile->sect_index_text = 0; if (objfile->sect_index_data == -1) objfile->sect_index_data = 0; if (objfile->sect_index_bss == -1) objfile->sect_index_bss = 0; if (objfile->sect_index_rodata == -1) objfile->sect_index_rodata = 0; } With the idea being that if every section has a relocation offset of zero then we can just point at any section. That's fine as far as the actual relocation offset is concerned, but sect_index_text is also used to find an objfile, and in this case, we need to point to an actual allocatable section. Maybe we should rewrite the 'if (objfile->sect_index_text == -1)' case so instead of always selecting index 0 we select the first allocatable and executable section? I had a go at this, see the patch below, and your test case still passes. I also wondered if we should be adding an assert to catch this problematic case earlier on? In buildsym_compunit::finish_block_internal where we do: symbol->set_section_index (SECT_OFF_TEXT (m_objfile)); this seems to be the first point where we could spot the problem maybe as this is where the offset to the wrong section is used for a symbol. Maybe here, or close to here, we could have an assert that the symbol has a valid objfile? I haven't exactly figured this bit out, but could be something to investigate. Anyway, let me know what you think of this alternative approach. Thanks, Andrew --- commit 12f7a855e97e6f4623607b2a503952ff8a7bb5c3 Author: Andrew Burgess Date: Wed Jul 29 18:21:12 2026 +0100 WIP: possible alternative diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c index 7df63856278..ca600a845e5 100644 --- a/gdb/breakpoint.c +++ b/gdb/breakpoint.c @@ -7764,7 +7764,7 @@ set_breakpoint_location_function (struct bp_location *loc) struct gdbarch * get_sal_arch (struct symtab_and_line sal) { - if (sal.section != nullptr && sal.section->objfile != nullptr) + if (sal.section != nullptr) return sal.section->objfile->arch (); if (sal.symtab != nullptr) return sal.symtab->compunit ().objfile ()->arch (); diff --git a/gdb/symfile.c b/gdb/symfile.c index 017f7a49d8d..ee1c40dada9 100644 --- a/gdb/symfile.c +++ b/gdb/symfile.c @@ -102,6 +102,8 @@ static int simple_overlay_update_1 (struct obj_section *); static void symfile_find_segment_sections (struct objfile *objfile); +static int symfile_default_text_sect_index (objfile *objfile); + /* Map from a BFD flavour to the corresponding sym_fns instance. On gdb startup, each object file reader calls add_symtab_fns() to register information on each format it is prepared to read. */ @@ -300,7 +302,7 @@ init_objfile_sect_indices (struct objfile *objfile) if (i == objfile->section_offsets.size ()) { if (objfile->sect_index_text == -1) - objfile->sect_index_text = 0; + objfile->sect_index_text = symfile_default_text_sect_index (objfile); if (objfile->sect_index_data == -1) objfile->sect_index_data = 0; if (objfile->sect_index_bss == -1) @@ -3706,6 +3708,48 @@ symfile_find_segment_sections (struct objfile *objfile) } } +/* Return the section index of a section in OBJFILE which can act as + the default text section. + + This returns the first allocatable and executable section, or the + first allocatable section if no section is marked executable. + + As an absolute fallback, 0 is returned. */ + +static int +symfile_default_text_sect_index (objfile *objfile) +{ + gdb_assert (objfile->sect_index_text == -1); + + bfd *abfd = objfile->obfd.get (); + + int first_allocatable_section_index = -1; + + for (asection *sect = abfd->sections; sect != nullptr; sect = sect->next) + { + /* Skip non-allocatable sections. */ + if ((bfd_section_flags (sect) & SEC_ALLOC) == 0) + continue; + + /* Record the first allocatable section. */ + if (first_allocatable_section_index == -1) + first_allocatable_section_index = sect->index; + + /* Return the first allocatable code section found. */ + if ((bfd_section_flags (sect) & SEC_CODE) == SEC_CODE) + return sect->index; + } + + /* We didn't even find an allocatable section. Return 0, but this + is likely going to cause issues if (somehow) there are any debug + symbols in OBJFILE as those symbols will end up with a NULL + objfile pointer. */ + if (first_allocatable_section_index == -1) + return 0; + + return first_allocatable_section_index; +} + /* Listen for free_objfile events. */ static void