This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: RFC: Avoid calling XXX_skip_prologue for assembly code



[I sent that last reply sooner than I intended.]

Fred Fish <fnf@www.ninemoons.com> writes:
> There is little point in attempting to skip over prologues if we
> already know for a fact that the source language is assembly.
>
> In fact, attempting to do so may actually be incorrect if the user has
> taken the output of the compiler, used that as the basis for his code,
> and hand optimized it in some way to produce an assembly version.
> There could still be prologue code in the hand crafted version.
> 
> Another way to handle this issue would be to have each of the
> "XXX_skip_prologue" functions in the various XXX-tdep.c files do their
> own checking first to see if the language is assembly, but they don't
> have easy access to that info, and each of them would have to do
> something similar to this patch anyway, so it seems more logical to
> just do the test in one place.

Andrew Cagney pointed out to me that gdb.asm/asm-source.exp actually
does try to get a backtrace from an assembly language function, and
expects to see the right function names.  For that to work, we need to
skip prologues.  But that test may be resting on some questionable
assumptions.

You're right, of course, that GDB really has no basis on which to make
assumptions about how an assembly language function lays out its
frame, or even that a symbol represents a function's entry point.  But
given how common it is to mix C and assembly language, it's also not
entirely unreasonable to ask for a backtrace.

I tend to feel that, if someone wants to see a backtrace out of a
hand-coded assembly function, they can set their breakpoint at the
right place themselves; GDB simply hasn't enough information to do it
for them.

I'm ready to approve this patch, but I think Michael Snyder might be
able to help me think about this more clearly, so I'm waiting for a
call from him.


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