This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] let record_resume fail immediately on error
- From: Hui Zhu <teawater at gmail dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Michael Snyder <msnyder at vmware dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 14 Oct 2009 10:27:48 +0800
- Subject: Re: [RFA] let record_resume fail immediately on error
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <4ABE5E8D.email@example.com> <firstname.lastname@example.org> <20090928160728.GB9003@adacore.com> <email@example.com> <20090929212910.GG6362@adacore.com> <firstname.lastname@example.org> <20091014021007.GO5272@adacore.com>
I think explain is very hard to make you happy with this patch. I am
really not good at it. Sorry for it.
Could you please try the example?
main(int argc,char *argv,char *envp)
Without the fix error patch:
we will get:
During symbol reading, DW_AT_name missing from DW_TAG_base_type.
Temporary breakpoint 1 at 0x8048352: file 4.c, line 14.
Starting program: /home/teawater/gdb/bgdbno/gdb/a.out
Temporary breakpoint 1, main (argc=<value optimized out>, argv=<value
optimized out>, envp=<value optimized out>)
14 asm ("rdtsc");
Process record doesn't support instruction rdtsc.
Process record doesn't support instruction 0xf31 at address 0x8048352.
Process record: failed to record execution log.
Program received signal SIGABRT, Aborted.
main (argc=<value optimized out>, argv=<value optimized out>,
envp=<value optimized out>) at 4.c:14
14 asm ("rdtsc");
Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb) record stop
Process record is not started.
On Wed, Oct 14, 2009 at 10:10, Joel Brobecker <email@example.com> wrote:
> It looks like you might be waiting for input from someone, or for
> approval? I confess that I'm still completely confused as to what
> the problem is and how you're resolving it. ?I don't want to be
> the one slowing you down, so if Michael is happy, I'm happy. ?But
> if you'd like me to take a look, can you try to explain the issue
> in a different way?
> For instance, I asked:
>> In other words: If an error occurs during recording, somehow
>> the inferior "runs away", meaning runs until completion?
>> Do we lose the process record?
> I was mentioning this as being the current behavior, which
> presumably is wrong. ?Am I correct?
> I also asked:
>> Based on the transcript of the session *with* the patch you propose,
>> it looks like GDB is now just stuck on that instruction that it does
>> not know how to record. Is that really progress?
> I am now refering to the situation *AFTER* your patch is applied.
> I couldn't understand the answer to sent or how it was relevant to
> my question.