Hi there,
First of all, thank you for doing this series.
I find systems programming fascinating but its really hard to get into using online resources.
This is the only project I have found so far that goes "down to the metal" while still being easy to follow.
The C feature that allows you to manipulate the pre-processor and change the file/line info for debugging is really cool; I never heard of it before.
If I understand it correctly, variable names in the watch window "just work" because they are the same in the generated C code as in ion?
Do you think this will become a problem in the future when the compiler needs to rename variables or functions (i.e. to support function overloading or local variable shadowing)?
First of all, thank you for doing this series.
I find systems programming fascinating but its really hard to get into using online resources.
This is the only project I have found so far that goes "down to the metal" while still being easy to follow.
The C feature that allows you to manipulate the pre-processor and change the file/line info for debugging is really cool; I never heard of it before.
If I understand it correctly, variable names in the watch window "just work" because they are the same in the generated C code as in ion?
Do you think this will become a problem in the future when the compiler needs to rename variables or functions (i.e. to support function overloading or local variable shadowing)?
Edited by Mathijs
on
Reason: Initial post
Yes, the names line up because they're translated 1:1 right now.
There should never be any problem with non-global symbols since those won't need renaming. I mentioned in the day 14 stream that once we add support for packages we'll prefixing generated global symbols in the C code with the package name. I still don't think that'll be too confusing. Probably 99% of global symbols are functions and you'll mostly be seeing their renamed symbols on the call stack where the prefixing is self-explanatory. For global variables, as the programmer using the debugger, you have to know that it's happening and take it into account when typing names into watch expressions--it should just be a minor inconvenience. For what it's worth, the same issue exists when debugging C++ code with namespaces. The debugger isn't namespace scope aware, so watch expressions that reference symbols in a C++ namespace have to use the fully qualified namespace path, e.g. foo::bar::baz rather than baz.
There should never be any problem with non-global symbols since those won't need renaming. I mentioned in the day 14 stream that once we add support for packages we'll prefixing generated global symbols in the C code with the package name. I still don't think that'll be too confusing. Probably 99% of global symbols are functions and you'll mostly be seeing their renamed symbols on the call stack where the prefixing is self-explanatory. For global variables, as the programmer using the debugger, you have to know that it's happening and take it into account when typing names into watch expressions--it should just be a minor inconvenience. For what it's worth, the same issue exists when debugging C++ code with namespaces. The debugger isn't namespace scope aware, so watch expressions that reference symbols in a C++ namespace have to use the fully qualified namespace path, e.g. foo::bar::baz rather than baz.
Edited by Per Vognsen
on