RFC: AArch64 Disassembler: Annotate undefined instructions

[Alice Carlotti]

On Thu, Jul 30, 2026 at 12:09:14PM +0100, Nick Clifton wrote:
> Hi Alice,
> 
> > I think Richard and I came away with a different impression of how this
> > conversation concluded.  We thought that the patch was not accepted and would
> > be dropped after this response, but I've just discovered from the release notes
> > that it was actually committed.
> 
> Ah, sorry.  That was obviously me not reading your emails correctly.
> 
> 
> > The issues I see with it are that it:
> > - Conflates 32-but values with 64-bit address, with the full address displayed as:
> >      411030:       0040065c        .inst   0x0040065c ; [func1]
> >      411034:       00000000        udf     #0
> > - Only supports symbols at addresses between 0 and 2^32-1
> 
> True.  I suppose that the heuristic could be improved to test to see if a
> following 32-bit value could be combined with the current 32-bit value to
> make a valid symbolic address.  But if you are already unhappy with the
> feature then maybe this is going a step too far.
> 
> 
> > - Only supports 60% of the addresses in that range, since 40% of values are
> >    recognised as instructions.
> 
> > - Interprets content as data values when the user explicitly requested the
> >    content to be interpreted as instructions.
> 
> Does it ?  The heuristic does check to see that it is in the MAP_DATA state
> before displaying the annotation, so values inserted as instructions should
> not be annotated.

I'm referring to the user who runs objdump, not the user who creates the
binary.  It looks like it will usually require the objdump -D option to get any
of these notes emitted.

Alice

> 
> 
> > Now that it's made it into a release, it might be a bit late to remove this.
> > However, if we keep it then I'd certainly want to explain some of the above
> > issues in the code comment, to reduce confusion there.
> 
> I have no problems with that.  It might also be useful to update the documentation
> to indicate the potential problems with the feature.
> 
> Cheers
>   Nick
> 
>