Euphoria
Ticket #622:
call stack
-
Reported by
useless
Feb 26, 2011
[15:18] * katsmeow-afk wants to ask for a feature she's asked for many times before, again
[15:19] <katsmeow-afk> access to the proc/funct call stack, to know what source code line called the procedure/function
[15:19] <katsmeow-afk> only way to do that currently is with trace on and to crash the program
[15:20] <katsmeow-afk> if the data is available during crash, can it be available before crashing?
[16:04] <mattlewis> katsmeow-afk: sure, it could be...that would be a great addition to tracing...put a ticket in for that, please
[16:12] <katsmeow-afk> matt, i asked for it pre-4.0, pre 3.1, i think back in the 2.5 days
Ok, everyone rip me a new one....
Details
1. Comment by DerekParnell
Feb 26, 2011
By "access", what exactly are you needing to happen.
2. Comment by mattlewis
Feb 26, 2011
My assumption was that there would be some command, when in trace mode, that would display the call stack. At a minimum, show the stack of calls (routine, file, line number). Ideally, there should probably be a way to navigate through that to look at variables in the various scopes at each level.
3. Comment by DerekParnell
Feb 26, 2011
A new trace-mode command to inspect the call stack etc would be a very nice addition.
I was wondering if Kat meant other forms of access such as a 'dump' to stdout of the call stack without actually crashing the program. Or a run-time function that returned the call stack data as a sequence.
4. Comment by useless
Feb 27, 2011
If i have a routine that's called by many many places all over an application, and i have that routine bracketed by with-without trace, i have no idea, while i am tracing thru the routine, of who called it. I believe it's a good feature to be be able to query a variable such as "called_by", or the entire call stack, such as call_stack[$-1], to figure out how it got where it is. Line numbers within filename.e would be preferred, as the line which called the routine is probably the same throughout the application.
If it is no more trouble, then what Matt suggested is even better.
useless
5. Comment by mattlewis
Apr 24, 2011
I'm thinking that this should be implemented in a few steps:
- Add a new machine func that would return the call stack information.
- For translated programs, I think we could add a new with call_stack directive, or something, that would inject and remove call stack layers as the program progressed. Obviously, this would slow things down, which is why it would be opt-in, since most people wouldn't want / need it.
- Update the debugging code to use this information (as mentioned, to browse up and down the call stack)
- In the built-in C version
- In the front-end / euphoria version (see ticket:506), we could use this however we'd like.
GitHub