This is the mail archive of the gdb@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: How to show instructions in one record


2016-09-06 12:04 GMT-04:00 Jan Kratochvil <jan.kratochvil@redhat.com>:
> On Tue, 06 Sep 2016 17:43:06 +0200, 慕冬亮 wrote:
>> I just want all the instructions which have already executed in one
>> execution path. Take the following demo as example,
>
> One can do some:
>         start
>         record
>         cont
>         <ctrl-c>
>         reverse-continue
>         while 1
>         stepi
>         x/i $pc
>         end
>
>

Thanks for your solution.

>> What I need is the instruction list:
>>
>> 203             movq     %r9, 16(%rdi)
>> 203             movq     %r9, 16(%rdi)
>> 202             movq     %r8,  8(%rdi)
>> 201             movq    %rax,   (%rdi)
>> 199             movq    24(%rsi), %r10
>> 198             movq    16(%rsi), %r9
>> ......
>> If there are loops, I need all the instructions in the loop.
>> I don't know whether process record/replay could achieve this goal.
>
> But I think in thise case you should follow Markus Metzger's advice as the
> output from 'record instruction-history' may be more appropriate for your
> requirement.
>

Yes, you're right. I am trying to configure driver for Intel PT.

> Besides building GDB yourself you can use also Fedora 23 (and better Fedora
> 24) GDB which does have libipt support.
>

I am using Debian Testing which ships extremely new software and is
rolling to some extent.
Debian has the support for libipt and I have installed this package.

> Be aware with btrace you cannot investigate any data or registers during the
> recorded execution.
>
>
> TBH I see this "display all recorded history" common request from GDB users
> but IMO more effective approach is to place there watchpoints, breakpoints and
> even breakpoint-attached command lists to catch the interesting moment during
> execution.  The recorded history is huge and so one needs to filter it somehow
> automatically afterwards anyway which the watchpoints solve on their own
> already during execution.  Sure it may not be applicable for your case.
>
>
> Jan


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