This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [patch v6 00/12] branch tracing support for Atom
> -----Original Message-----
> From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]
> Sent: Thursday, December 20, 2012 12:30 PM
> > How do you like temporarily adding debugger variables "$end", "$start", and
> > "$here" and accepting the same syntax that list and disas accept? I don't
> > know how difficult that will be to implement, though.
>
> I find it overengineered, "record list $end-42" I find already more
> complicated than a new command "btrace list 42".
My use case is to start with looking at the last 20 or so instructions. If that's not enough, I want to look at the next 20. This would not be supported by just adding "record list last <n>".
> I do not find great that current record.c numbers history one way and btrace
> would number history the opposite way. I find the default direction should be
> the same and it should be easy enough to type each time.
I wanted to keep the numbering of record/replay. That's why I added those variables to be able to express what I want.
Personally, I find the opposite numbering, i.e. from newest to oldest, more intuitive and more useful, since I'm typically more interested in the tail of the trace than the head.
Is the instruction number used anywhere outside "record goto"?
> But I find / you are right that implementing even reverse-step is an add-on
> work, not requiring much to rewrite the existing code. The storage of history
> information between record.c a btrace.c needs to be completely different
> anyway.
>
> So I agree now the reverse-* compatibility is outside of the scope of the
> initial commit.
Glad to hear that.
> > As will next and finish when inside the history. I don't know how
> > much I will be able to reuse from the record/replay implementation.
>
> Probably not at all. Just there should remain the same to_resume/to_wait
> hooking.
I'm not familiar with the implementation. I would expect, though, that it won't be enough to implement to_resume and to_wait hooks. I would rather expect that I will need to implement new stepping commands. I further expect that I would need to replace frame unwinding. For all other commands, I can only hope that gdb is OK with a target that can read (not write) RIP but no other register and that can access only code memory.
Regards,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052