[PATCH v2 08/15] MIPS: Mask off lowest bit when disassembling compressed code.

[Maciej W. Rozycki]

On Thu, 30 Oct 2025, Jovan Dmitrovic wrote:

> >   Please explain in the commit description why this change is needed.
> > Also do you have a test case, does it happen in reality?  And does this
> > change affect GDB?
> 
> Apologies, I thought that ChangeLog description was enough,
> considering it is a change to a single file.

 We have actually mostly abandoned the use of ChangeLog entries throughout 
the toolchain projects.  Only GCC still wants them, with binutils they're 
entirely optional and most people stopped using them, and glibc and GDB no 
longer accept them.

> As stated in the patch itself, I didn't write it,
> I only adapted it (this and other patches have been used
> in the industry for a long time). Unfortunately, the exact
> reasoning behind this patch was lost somewhere along the way,
> so I don't have a test case at the moment.

 And that's the very reason why we want to have the rationale written down 
in the change description.  Had we had one from the original author here, 
we wouldn't have to wonder what the change is good for.

 Likewise we don't want someone to scratch their head who has an issue to 
sort out or makes changes in the area and comes across a commit in several 
years' time.  I've been through this before myself and I tell you it isn't 
nice at all.

>  From what I gather, this patch only comes into play if something went
> horrifically wrong while assembling - if we could reproduce
> this via gas, it would make more sense to fix it in gas itself, rather
> than introducing this as a workaround. My guess is that this change makes
> the disassembler a bit more resilient when it comes to erroneous input.
> I can't see how it could impact GDB in any other way.

 Well, we do not mask bits 1:0 either with regular MIPS code even though 
similarly it has to be 4-byte aligned for execution.  But the disassembler 
is a tool for humans and not the machine, so it should be flexible and not 
stand in the way.  Typically you reach for it when you have got a problem 
to solve already and then the last thing you want is to struggle with the 
tool as well.

 I mentioned GDB, because in GDB you can disassemble by the address, e.g.:

(gdb) x /i 0x01234567

and if there's no symbol information available for the location requested, 
then GDB is supposed to interpret the ISA bit from the address supplied.  
But then it's also meant to strip the bit before handing the address over 
to the disassembler too, so no such change as one proposed is expected to 
be needed (cf. `gdb_print_insn_mips').

 There might be a corresponding scenario in `objdump', as mentioned in the 
comment next to the code change (although with `objdump' I'd expect to use 
`-m mips:16' or `-m mips:micromips' to request compressed disassembly and 
let the address through unchanged).

 I don't think it has anything to do with GAS.  You can make GAS produce 
unaligned code, but then you can't do anything about it either, and maybe 
even want the disassembler to handle it undisturbed just to make people's 
life easier in figuring out what went wrong there.

 Please experiment with the change then and preferably find a test case 
that works as expected with the change applied and fails, in a legitimate 
way (i.e. it's not something one would expect from the way a tool has been 
used), without it.  It may also be the case that the original issue which 
has prompted the change has been since dealt with elsewhere.

  Maciej