|
|
jacob navia wrote, On 28/03/08 23:32:
Richard Heathfield wrote:
jacob navia said:
Flash Gordon wrote:
jacob navia wrote, On 28/03/08 21:39:
<snip>
5) Find out into which function the return address points to.
6) Is that the function "main"?
7) If not, get the next frame pointer and go to (2)
A problem if main was called recursively.
No. As I explained to Mr Heathfield, that raised the same objection,
my algorithm just stops at the first possible recursive call of main
It doesn't fail at all. It will not follow recursive calls to "main".
That is all.
Obviously, calling "main" recurisvely is very popular here.
Well, not really, but recursive main *is* legal. It seems to me that a
non-portable solution would be free to learn main's caller (e.g.
_startup, or whatever), and probe for that instead. This would allow
recursive main calls to be backtraced properly.
Assuming you can get a backtrace at all, which is not guaranteed.
<snip>
In principle you are right, and I considered that. Problem is, my
startup is obviously not written in C but in assembler... It would
have been quite impossible to write it in C actually...
With a few extensions you can. At least, I've worked on Pascal
implementations where the startup code was written in Pascal (+
extensions) and this is the same problem.
In my context, My assembler doesn't know how to emit debug information,
so there is no debug info.
Then perhaps you should change your assembler so that it does include
the basics. Most assemblers do.
For startups written in C, your idea would work.
Or for ones written in assembler where the assembler supports debugging.
--
Flash Gordon
|
|