RFC: AArch64 Disassembler: Annotate undefined instructions

[Richard Earnshaw (foss)]

On 28/04/2026 15:14, Michael Matz wrote:
> Hey,
> 
> On Tue, 28 Apr 2026, Nick Clifton wrote:
> 
>>>>>        41fdd8:	00400764 	.inst	0x00400764 ; undefined
>>>>>        41fddc:	00000000 	udf	#0
>>>>>
>>>>>    Whereas with the option enabled this changes to:
>>>>>    
>>>>>      000000000041fdd8 <__frame_dummy_init_array_entry>:
>>>>>        41fdd8:	00400764 	.inst	0x00400764 ; [frame_dummy]
>>>>>        41fddc:	00000000 	udf	#0
>>
>>>> This is what mapping symbols are supposed to address.  If the user writes
>>>> '.word' in a code section then the value will be tagged with $d and the
>>>> output should then disassemble as data.  '.inst' means 'this is an
>>>> instruction'.
> ...
>>>   objdump -d test.o
>>>
>>> Maybe .word should be annotated with a suitable label, but I don't think
>>> .inst should.
>>
>> OK, that makes sense.  So the disassembler should check to see if closest
>> previous mapping symbol is $d and only proceed with the annotation in this
>> case, yes ?
> 
> But we're talking about doing the annotations for a final-linked file, not 
> for relocatable files.  Are the $d symbols even part of them?
> 
> (And it's an annotation only, I think it'd be acceptable to say "[foobar]" 
> even when an undefined instruction really was meant as undefined 
> instruction, not as .data, but just so happens to match the address of 
> foobar.  It certainly would be a very interesting coincidence, and also 
> certainly much more interesting than "; undefined". )
> 
> 
> Ciao,
> Michael.

They're in the symbol table.  If you strip the symbols you'll lose the information.  But then you'd lose the symbols that Nick is proposing to annotate as well.

I guess you could selectively strip some symbols, but then it's a matter of caveat emptor.