----- 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
