----- Original Message -----
On Mon 2015-08-10 09:13 -0400, Dave Anderson wrote:
>
>
> ----- Original Message -----
> >
> >
> > ----- Original Message -----
> > > Dave,
> > >
> > > Since our last discussion [1], a further change to the
"consolidation"
> > > patch has been made. The assumption now is that the text address
generated
> > > by gdb is _always_ in base 16 form. Hence the if clause to check buf2 is
> > > prefixed with 0x has been removed as indicated in the hunk below:
> > >
> > > - if (STRNEQ(buf2, "0x"))
> > > - extract_hex(buf2, &curaddr, ':', TRUE);
> > > + extract_hex(buf2, &curaddr, ':', TRUE);
> > >
> > > Please let me know if this assumption is valid.
> >
> > I don't think it is.
> >
> > The reason for the "0x" check is that gdb may split a single line of
disassembly
> > into two lines, or at least it used to. As I recall, I think I later added a
gdb
> > option initialization to prevent that from happening (?, but nonetheless, it
could
> > still be undone by the user. So it's best to leave the check in place.
>
> BTW, that's what all the ":" checks are there for, both in cmd_dis()
and in the
> per-arch dis_filter functions. When gdb would split the line, it would end the
> first line with the colon following the text address and offset.
OK shall I post a v2 to put the if clause back?
As long as your patch doesn't make other presumptions that the gdb output is
necessarily a one-liner, then I can add it back for testing.
Dave