From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id iitVAb4niGqbizMAWB0awg (envelope-from ) for ; Fri, 21 Aug 2026 06:26:06 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=embecosm.com header.i=@embecosm.com header.a=rsa-sha256 header.s=google header.b=e26GSUZO; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DA5071E033; Fri, 21 Aug 2026 06:26:05 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 D19111E033 for ; Fri, 21 Aug 2026 06:26:04 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1BDD64B99F79 for ; Fri, 21 Aug 2026 10:26:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1BDD64B99F79 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=embecosm.com header.i=@embecosm.com header.a=rsa-sha256 header.s=google header.b=e26GSUZO Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 0DC084B9DB6E for ; Fri, 21 Aug 2026 10:25:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0DC084B9DB6E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0DC084B9DB6E Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::42e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787307935; cv=none; b=ASOXW/+KT3cAJ7vSs1/VgTh+RqUJmnk7OhUeSOyDLs3fzeqfU1Q8NaIAUlpgU6APtEqBQEW4S0IcYooF/jTqQofdgxsCanNg0AshGtjl8KMv+IUawYfJvhYyBgunqMUVJfrGAs+GrsJD5ISwmg88BLZXEOPEOIeZ1o2EyR2kYf4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787307935; c=relaxed/simple; bh=XC91nU8DgXpabP2kxVmwmF6oIq5jFbYdw0mLUY9zTjY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=l4EIcNTm5sdp/kpWpnig4BLIkqh65WatTlh/yD1ihWb+ISQ04bCQ8VNt3gf8vXki8VmY0T1Sj9nim/elDfPWPm9LeVht3OzCUeJq+QoaAyKb83jxT8dj39x59lT1nDDS7va8T4fx2nRzxKXvtEjdl0/BbDHvGkevBkYFpMY0E5Y= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=embecosm.com header.i=@embecosm.com header.a=rsa-sha256 header.s=google header.b=e26GSUZO DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0DC084B9DB6E Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-47db714766aso1318260f8f.0 for ; Fri, 21 Aug 2026 03:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; t=1787307931; x=1787912731; darn=sourceware.org; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:content-type:from :to:cc:subject:date:message-id:reply-to:content-type; bh=b3yc8dppWoSlOhaBk/MdhFY2Stx5FABiYHG8VOK6C5A=; b=e26GSUZO+ZWv3MHs5T6H2PYjglCiAKvnJXAr4R3gbLZuVJbUMuqq2UvnEf5rBOrhEX gnsIdTQ09ozQQYJQ45fDnJoQPEY1PivYOGvtNyr6KkiEAdlAdh5osOqwu7ZB19l2GFjM fnK7YqHEVfnRdqyIQylG/QkcRyPt9BaLjKuZx7BcXs72Etk6jK93E27WpEYyOJnzC32z w+IUagSgPwiHRFT/PZFA9P2HMCMMGle3iOQAKuJhHJuFyguCbDpn2qbqI9dGQLkkVkby cmh7YsiHyGFNgXucEVIvN4kKLxfcfzgdKj31X1Vj2HsDP3QJwn5pfRdGxd53N4NrPIW8 fccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787307931; x=1787912731; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:content-type :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=b3yc8dppWoSlOhaBk/MdhFY2Stx5FABiYHG8VOK6C5A=; b=tRlr75ptjyEy+FVsWjOht3i0ylH13pAixPuwytPYTGT33KHo6gx3EQQe3GVsUg4guP 8fNMtVqwOl7gTTplFns1DokdzPLAuBD6ZolblWGivrhJsf2Tkc+1H6fPaSzgGvs9HDBO ZZLCq1MqQ7ud7ZYwlvTSSr0fchLgIIpnFt0kBZAHeCR5b33V8TjBXdxKjXhBQIz50Nya bnkAyIBmeRrI34dlWbRVA2akSlwXVUtWIP4CgFgc06mtJFBL4XawulMFOCsqTQpRa60w iUDMoMwvCm65auH+cofpXx9/wMI/eUofdccCLmXZvclxcizsIYgiCrKN2se80/5XrXMr 3z/A== X-Forwarded-Encrypted: i=1; AHgh+RpeTsaFSij5l4Kom0bmdL4zJIrWmVnDUQvc/XTkSQZceCPZGIQtwuwHacXt4zr9LncATnvEtQYZT3BoTg==@sourceware.org X-Gm-Message-State: AOJu0YySijX+/ayd7Fj1RE+MEvOhPCMK0M+PTcGvIWYTYH1g4A0KOeSy aB3MoKlHlQwHawGKcT9w8PsdsoLjumZglUky4GfHTA6FjFIIIXKvgigfU+AbFOtEfBilojkNQHq d5z9P/jg= X-Gm-Gg: AR+sD11eL4Xc0xJ2yEJR6Q2GyAMoST+X+TKkNve43DoPygWYSN9XHS9aFA4qcCwleff KKpo3i0KBSLeOovBzM0AgjqzcvN+AZNTvdsg3xgC6HpfRZgFAhvc+pJo7xt1LYKb8RBEXa+1xed uk4pZSoMVJi2x1OfB1YXVbRHndGbAdS8HuU11Nn9F97yQWaNEwYr6Iz4yd1buNxgdj0XtGKa++Y tiSiz51RYldF4WyI5CHUzthkhHGrjpbAnlpgEzaQ7ed+WvreEWHzbMQMD0P7Wa88TtHKU42TRnt 5AbI+QtTW63lcjLo4MmIr0oPsgNTKObex4gfX98uys0GAKTuh1AYKouSTS7pgz/KPlqhDmuNcdZ yXlWombAf/+jnvbfdYRdbBB4S+AVaOeFfp8BFxsiLbc/+XepXRM1va1C4NKN7hZfGEATfBxt9cD qHegqxt1R9tlHJrncDfjRtb0p4bjeCoYrCV0SP8gh1TRJMVrhiE1+Da1Eqj0IkeWnSXTib5wkMW y6S4UqgCl/QT9TDe6xtEszjixUai886MxqeGcc3fqL+/q1DsKlF4Npg58lHF6+FJK4dx365DZM= X-Received: by 2002:a05:600c:4688:b0:499:5f80:83ac with SMTP id 5b1f17b1804b1-499b91ad940mr41300545e9.7.1787307931398; Fri, 21 Aug 2026 03:25:31 -0700 (PDT) Received: from [192.168.0.55] (sals-04-b2-v4wan-167965-cust660.vm36.cable.virginm.net. [80.3.10.149]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499b9b81602sm14679205e9.3.2026.08.21.03.25.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Aug 2026 03:25:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------ngGtmHvDuJKnYWxbHkH07XV4" Message-ID: <4ecef44c-61e1-4f20-ae9d-d177edd429e1@embecosm.com> Date: Fri, 21 Aug 2026 11:25:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Add missing null pointer check in get_sal_arch To: Andrew Burgess , gdb-patches@sourceware.org Cc: Simon Cook References: <20260729150617.3502554-1-craig.blackmore@embecosm.com> <87ik5vmdsi.fsf@redhat.com> <87fr0zmb79.fsf@redhat.com> Content-Language: en-US From: Craig Blackmore Autocrypt: addr=craig.blackmore@embecosm.com; keydata= xsBNBFdIF8oBCACwrsvc6YVfzJRT+ZoBfL9jEb8ITwNahDxCGSG6sIWrJ9UFeTwE8fnNhMpz RyFRm0OXruS5k/8YHJHrxKxFY9cgZ3CWNftXEjRqURUWGtN/ESiw0J7nVfhSGQTo3LBzpXZ1 0JHk4ZHKDJKYa+fhybCHOs19BfP3HydHoTlc5QTKMfom0X/xo7WDdwUYeZsjD9u8IzHk7gNw 05Abk1vqni+J7Fghjp4RI8W3IsjpKOfV3f02OyO/MTSraXNyejO4JRl0A8b3q1Lq+G6Z7o5n LVief5JpkRyzWQSawTIBKmRZa9EzAKZXd6IJdY/sZt7pTir5EP7MHq4a+AtKfKuDkrDDABEB AAHNLkNyYWlnIEJsYWNrbW9yZSA8Y3JhaWcuYmxhY2ttb3JlQGVtYmVjb3NtLmNvbT7CwHgE EwECACIFAldIF8oCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGEeRQLLl5WtydMH /1nYd9jmOBaF8w5gGgjF5eOO5b/cdUegmO///VYj/5R7iF/zbB6KgF0Obo5h2gG9AIfsZG+T ybuTx7oU1DZYEIndw+YP9c9Yi5de5UzEHwbJiV57W0n+MP0Widgw7p6XJmUQ1XbHxdcWp7nY EJa8ASKLuuIhO8JFUXbQ8BcUiWbsA/JxgCzeid8iixGrzPWj6iFzoK2mX4GqP+24pXSDUamM TXmSQd2taYEsyUdJNiEkUC51ncRcMuThjdtfn6Ok+7lHjh3Zz8q0keJz5pnIp4EXdkAgKSjq U42PMrd3v1HoIFINTtr5F23OdkxoQzysu4GMO4pkw5pwz95Uckr08ojOwE0EV0gXygEIAKv/ luYHmCG/qefgzdbnegwMdG5753NJ+zGxFltFX6aaOPZ8go9Omf6zwjybUKv6Qx6AlDanwCl3 ewVQs+h9iW8uaQBRgeDmwAGMG/doBiFqs7X0jBf23exMiJezXlKb2ZlKzMAbzJ87408AzRaV sZdwEpXHVi2mRPoXtMrqL5iQEyG5hdx2ySj5164DIgVOs/ypFiaiFaDPkIcAQTzJrxsbt6pf iI9kT93DO9nRKVV0pPWztV8P5gKM8HY2rS0wQcfrqAU6T89Aa0VFw92J+w5d2spF8MUNPsvR NLm9ooCF3YME9STYHXrNH1U9fJUWpIC+b49UoWSWRD9nwl2h2i8AEQEAAcLAXwQYAQIACQUC V0gXygIbDAAKCRBhHkUCy5eVreLbB/sHPs1xu78uNV8O4UPTX7D5zBBS3nsrbDr+8stmXRap xbvo6kqKzIMAXuO3bYB/NyJ/tFzuFr9Tjd/2g56D2186bp01/kgxJ9CEl/m2T3lG3DlxIoLg pCExzTLTb8zH/7/6mdeJ17cdnrK+2QAKYctReVPAC67cq5KmUyU3bv5e1JzhV4ezz/i/O+Jv el112ZEsa54ya9KZOUHbgAR6hLnRWIa+8yQTtXqYRc3LxLRfS80Wn0Err1YvqFYzJsQMC8ND xAeEuqQ1gfk1b0jmv7tYljNqsHqzGVbuWz6hyzyLv5GjcdSDKpbw/797gRKQSY8Gty5ynfUH O4kKyuZPrE8P In-Reply-To: <87fr0zmb79.fsf@redhat.com> 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 This is a multi-part message in MIME format. --------------ngGtmHvDuJKnYWxbHkH07XV4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, On 31/07/2026 16:27, Andrew Burgess wrote: > 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 for looking into this and sharing your analysis and alternative fix. I much prefer your fix as it addresses the root cause and it works on both my original test and the updated test that I just posted. As you've written the fix, would you prefer to add my test to your patch or for me to combine everything into a new submission? Thanks, Craig --------------ngGtmHvDuJKnYWxbHkH07XV4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi Andrew,

On 31/07/2026 16:27, Andrew Burgess wrote:
Andrew Burgess <aburgess@redhat.com> writes:


Craig Blackmore <craig.blackmore@embecosm.com> 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 for looking into this and sharing your analysis and alternative
fix. I much prefer your fix as it addresses the root cause and it works
on both my original test and the updated test that I just posted.

As you've written the fix, would you prefer to add my test to your patch
or for me to combine everything into a new submission?

Thanks,
Craig

--------------ngGtmHvDuJKnYWxbHkH07XV4--