This is the mail archive of the gdb@sourceware.org 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] |
Other format: | [Raw text] |
So you're saying you have to do (A) backwards code analysis from the
call site to compute r29, and then (B) forward code analysis from the
function start to compute r20 relative to r29, and then (C) use dwarf
debug information to find arguments relative to r20, and then (D) hope
that GCC doesn't decide to use r20 for something different, since it
doesn't seem to be a traditional "frame pointer"? There's a lot more
prayer in that method than there really ought to be.
probably take some severe liberties with where the set of %r29 is, so I'm skeptical that you can do the call site analysis.
How does GDB cope today? A lot of guessing and failing?
I'd recommend ignoring the call site/ABI bits. They're too unreliable. The real problem is that you can't recover %r20. You're thinking in terms of finding the offset relative to the CFA where these things are stored, which is why you've got a solution that relies on analyzing the caller. But think about the problem in terms of the callee for a moment. The function doesn't care what the offset relative to the CFA is. It cares what the offset relative to the incoming %r29 and later %r20 is. And then, if it makes any calls, it had better still know where its own arguments went! So that should be in the debug info somehow.
We've got dwarf unwind information to play with now. Even with the new
additions in dwarf3, it's not so good at representing what you need. I'd need to see a larger example to know how we could, or couldn't, do
this.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |