This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 6/8] Return -1 on memory error in print_insn_m68k


On Thu, Jan 12, 2017 at 02:52:30PM +0000, Yao Qi wrote:
> On 17-01-13 01:08:14, Alan Modra wrote:
> > On Thu, Jan 12, 2017 at 11:50:21AM +0000, Yao Qi wrote:
> > > On 17-01-12 08:45:14, Alan Modra wrote:
> > > > On Tue, Jan 10, 2017 at 12:26:16PM +0000, Yao Qi wrote:
> > > > > 	* m68k-dis.c (match_insn_m68k): Extend comments.  Return -1
> > > > > 	if FETCH_DATA returns 0.
> > > > > 	(m68k_scan_mask): Likewise.
> > > > > 	(print_insn_m68k): Update code to handle -1 return value.
> > > > 
> > > > This misses one FETCH_DATA call, in m68k_scan_mask.
> > > > 
> > > 
> > > I can't remember the reason I didn't change it.  Sorry.
> > 
> > Actually there is a good reason not to change that call, I just didn't
> > look at the code well enough and thought you'd accidentally missed
> > it.  The previous patch is OK.  The newest one would fail if you had
> > a 2-byte insn at the end of a segment and happened to try a 4-byte
> > insn match first.
> >
> 
> Hi Alan,
> This won't happen in the 2nd patch, because if the instruction is 2-byte,
> it won't read and match the next 2 bytes.  There is a guard
> ((0xffff & match) != 0) for read.  Am I missing something?

The code is looping over an opcode table.  You might try to match a
4-byte instruction from the opcode table before matching the 2-byte
instruction you have.  If you exit the loop due to failing to read 4
bytes then you won't disassemble the instruction.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]