From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: fnf@ninemoons.com Cc: gdb-patches@sources.redhat.com Subject: Re: RFC: Avoid calling XXX_skip_prologue for assembly code Date: Thu, 11 Oct 2001 13:22:00 -0000 Message-id: References: <200110051954.f95JsNn07270@fishpond.ninemoons.com> X-SW-Source: 2001-10/msg00142.html [I sent that last reply sooner than I intended.] Fred Fish 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.