System Architecture (eg. arm, x86_64, ...): x86_64
Your problem description
debug_backtrace() and probably any other related function returns always 1 as a file line. Root cause is PH7 Engine not tracking line numbers at run-time. This is hard-coded in vm.c, lines: 9300 - 9304.
<!--
1. Please speak English, this is the language all of us can speak and write.
2. Please take a moment to check that your issue doesn't already exist.
3. Please give all relevant information below for bug reports, because
incomplete details will be handled as an invalid report.
-->
# Aer Information
- Aer Version (or commit ref): e53cfb8ba0
- Operating System: Linux
- System Architecture (eg. arm, x86_64, ...): x86_64
# Your problem description
debug_backtrace() and probably any other related function returns always 1 as a file line. Root cause is PH7 Engine not tracking line numbers at run-time. This is hard-coded in vm.c, lines: 9300 - 9304.
To implement this feature, in the compilation bytecode header must store a mapping of the opcode's position with the associated source code line.
source -> compile -> bytecodes + header with lines for each bytecode jump
This issue is a structural problem in generating the bytecode, which is necessary to generate with the header that contains this mapping.
For example, it follows the attachment how Java handles this mapping. This image is a example of method with yours bytecodes and yours lines associated.
To implement this feature, in the compilation bytecode header must store a mapping of the opcode's position with the associated source code line.
source -> compile -> bytecodes + header with lines for each bytecode jump
This issue is a structural problem in generating the bytecode, which is necessary to generate with the header that contains this mapping.
For example, it follows the attachment how Java handles this mapping. This image is a example of method with yours bytecodes and yours lines associated.
This is connected with #2, I think. There is a general problem with information about file & line position in PH7. FILE shows some trash, while debug_backtrace() simply gets currently processed file and returns only last callback instead of whole backtrace.
This is connected with #2, I think. There is a general problem with information about file & line position in PH7. __FILE__ shows some trash, while debug_backtrace() simply gets currently processed file and returns only last callback instead of whole backtrace.
Aer Information
e53cfb8ba0
Your problem description
debug_backtrace() and probably any other related function returns always 1 as a file line. Root cause is PH7 Engine not tracking line numbers at run-time. This is hard-coded in vm.c, lines: 9300 - 9304.
To implement this feature, in the compilation bytecode header must store a mapping of the opcode's position with the associated source code line.
source -> compile -> bytecodes + header with lines for each bytecode jump
This issue is a structural problem in generating the bytecode, which is necessary to generate with the header that contains this mapping.
For example, it follows the attachment how Java handles this mapping. This image is a example of method with yours bytecodes and yours lines associated.
This is connected with #2, I think. There is a general problem with information about file & line position in PH7. FILE shows some trash, while debug_backtrace() simply gets currently processed file and returns only last callback instead of whole backtrace.
gitea seems annoyingly to close the ticket once you mention it in a commit message.