[PATCH v2 0/2] opcodes/nfp: bug fix for nfp disassembler

[Yinjun Zhang]

+ Simon Horman in the loop.

> -----Original Message-----
> From: Alan Modra <amodra@gmail.com>
> Sent: Wednesday, September 1, 2021 9:25 AM
> To: Yinjun Zhang <yinjun.zhang@corigine.com>
> Cc: binutils@sourceware.org
> Subject: Re: [PATCH v2 0/2] opcodes/nfp: bug fix for nfp disassembler
> 
> On Wed, Aug 25, 2021 at 09:01:16PM -0400, Yinjun Zhang wrote:
> > This series is to fix some bugs in nfp disassembler.
> >
> > Yinjun Zhang (2):
> >   opcodes/nfp: add validity check of island and me
> 
> Thanks, I applied this one,

Thanks.

> 
> >   opcodes/nfp: skip those non-code sections
> 
> but won't apply this.  Disabling objdump -D is not a solution to bugs found by
> fuzzers, because a very simple change to the attack object will result in the
> same bug being exposed with objdump -d.  

Yes, you're right, and thanks for pointing this out, and I think that's why the previous
commit is needed and applied.

> The whole point of objdump -D is
> to disassemble non-code, knowing that it is likely to result in nonsense.

I understand "objdump -D" is to disassemble all sections, including those non-code
ones, however current nfp disassembly code is not prepared for that. Disassembling
those sections just result in meaningless output, so I propose to skip those sections
for now.

> 
> By the way, you have another similar problem in init_nfp6000_mecsr_sec
> with the menum calculation from a bit-field read from an object file.
> That also needs to be sanity checked.  Bit-field values of 0 to 3 in the file will
> result in out of bounds mecfgs array access.

I'd checked this part, you mean "menum = _BF (ireg.cpp_offset_lo, 13, 10) - 4", 
right? There's a "-4", so I think it's safe.

> 
> --
> Alan Modra
> Australia Development Lab, IBM