----- Original Message ----- > On Fri 2019-06-21 11:45 -0400, Dave Anderson wrote: > > > > > > ----- Original Message ----- > > > Changes since v1: > > > > > > - Update 'dis' help page > > > - Resolve patch fuzz > > > > > > > > > The purpose of this patch is to add support for a count value in reverse > > > or forward mode, during disassembly: > > > > > > 'dis [-r|-f] [symbol|address] [count]' > > > > > > For example: > > > > > > crash> dis -f list_del+0x16 4 > > > 0xffffffff812b3346 <list_del+22>: jne 0xffffffff812b3381 > > > <list_del+81> > > > 0xffffffff812b3348 <list_del+24>: mov (%rbx),%rax > > > 0xffffffff812b334b <list_del+27>: mov 0x8(%rax),%r8 > > > 0xffffffff812b334f <list_del+31>: cmp %r8,%rbx > > > > > > crash> dis -r list_del+0x16 4 > > > 0xffffffff812b333c <list_del+12>: mov 0x8(%rdi),%rax > > > 0xffffffff812b3340 <list_del+16>: mov (%rax),%r8 > > > 0xffffffff812b3343 <list_del+19>: cmp %r8,%rdi > > > 0xffffffff812b3346 <list_del+22>: jne 0xffffffff812b3381 > > > <list_del+81> > [ ... ] > > Hi Dave, > > > To be honest, it's not clear how that can be addressed, because any patches > > to printcmd.c must be applicable to the non-ppc64le and the ppc64le > > versions > > of the file. > > Unfortunately, I believe this is the underlying issue. > I did not compile test under ppc64le. > > > So let's take a step back, and consider the risk/reward of this quite intrusive > > patchset to such a crucial gdb file. > > In my opinion and if I understand correctly, the original GDB commit > bb556f1facb ("Add negative repeat count to 'x' command") is rather > self-contained and should not cause an issue. I was particularly careful in > this regard. Moving forward, I could strip out all but absolutely necessary > changes from the original GDB commit, to support this feature. > > > First, "dis -f <address> <count>" is pretty much meaningless. In order > > to accomplish that, just don't use the "-f" argument! > > I agree - this is superficial; count in forward mode was added since > reverse mode also accepts a count. > > > Secondly, for "dis -r <address> count", you could simply run "dis -r > > <address> | tail -4". > > For that matter, is it really all that onerous to see the fully > > disassembled function > > up to the target address? > > Personally, I would prefer to avoid using an external command in this > particular case. Especially since the GDB command examine supports a > positive or negative (i.e. in GDB release 7.12 and above) count. > > > And again, even if you wanted to support it, it also seems like it could be accomplished > > within the cmd_dis() function, given that the full output is pre-gathered into a tmpfile > > prior to being displayed. > > We can indeed but it would be easier to utilise GDB for this as explained > above. > > If you don't mind another iteration, I'll attempt to address the above > build issues. Please let me know your thoughts. I can't stop you from trying, but I have to say that you're not calming my nerves, because: (1) I don't care whether gdb-7.12 has that capability. (2) If it is at all possible to refrain from tinkering with the temperamental beast gdb, I would always rather do so. In the interest of simplicity and maintainability, it just seems that here in cmd_dis(): 2019 gdb_pass_through(buf5, NULL, GNU_RETURN_ON_ERROR); 2020 2021 if (req->flags & GNU_COMMAND_FAILED) { 2022 close_tmpfile(); 2023 error(FATAL, dis_err, req->addr); 2024 } 2025 2026 rewind(pc->tmpfile); 2027 while (fgets(buf2, BUFSIZE, pc->tmpfile)) { at line 2025, you could do something like: if (count_entered and reverse) set_reverse_offset(req->count); else rewind(pc->tmpfile) Your choice... Dave > > > Kind regards, > > -- > Aaron Tomlin > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility