Hi Andrew,
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.