hi,
I'm trying to figure out the code flow of gcc.But i'm not been
able to locate the location at which an expression is compared with
pattern given in .md file.
I think .md file is resposible fo generation of emit-insn.c
file.But again at which point the functions in emit-insn.c file
kernel coder writes:
> hi,
> I'm trying to figure out the code flow of gcc.But i'm not been
> able to locate the location at which an expression is compared with
> pattern given in .md file.
>
> I think .md file is resposible fo generation of emit-insn.c
> file.But again at whic
is there any way in gdb to step backward.
On 6/15/06, Andrew Haley <[EMAIL PROTECTED]> wrote:
kernel coder writes:
> hi,
> I'm trying to figure out the code flow of gcc.But i'm not been
> able to locate the location at which an expression is compared with
> pattern given in .md file.
kernel coder wrote:
> is there any way in gdb to step backward.
>
not yet, and if this feature is implemented it should be quite
restricted, think about undoing side effects, as disk read/write...
But you can put a breakpoint before the current point, and then run
again gdb on your program.
Sebastian Pop wrote:
kernel coder wrote:
is there any way in gdb to step backward.
not yet, and if this feature is implemented it should be quite
restricted, think about undoing side effects, as disk read/write...
But you can put a breakpoint before the current point, and then run
again gdb o
On Thu, Jun 15, 2006 at 10:05:10AM -0400, Robert Dewar wrote:
> You don't need to undo side effects for debugging purposes, you just
> need to be able to recreate previous states from the point of view
> of the application. So for I/O operations, you need to restore memory
> to the state before the
Daniel Jacobowitz wrote:
The point of going backwards (a feature quite familiar to me from
the use of hardware debuggers on PC's in bygone years) is to figure
out what went wrong, and for that purpose you only need to worry
about the machine/memory state.
Not when you're debugging userspace an
On Thu, Jun 15, 2006 at 10:31:55AM -0400, Robert Dewar wrote:
> Daniel Jacobowitz wrote:
>
> >>The point of going backwards (a feature quite familiar to me from
> >>the use of hardware debuggers on PC's in bygone years) is to figure
> >>out what went wrong, and for that purpose you only need to wo
Daniel Jacobowitz wrote:
> It doesn't have an actual reverse debugging implementation yet - but
> it's been proposed.
>
Here it is, but I don't know the exact current status of the proposal:
http://sourceware.org/ml/gdb/2006-01/msg00013.html
