dbgfile contains no reference to static locals
pm100 opened this issue · comments
the -g -dbgfile combination outputs a ton of info however it misses information on local static variables
int main{
int foo;
}
generates a .dbg that eventually ends up as a csym in the dbgfile
int foo;
int main{
}
generates a .export that ends up as a sym in dbgfile (but notably not a csym, and with the name '_foo', not 'foo', however functions in c get csyms with their c names)
static int foo;
in main(){
}
does not generate a .export but still appears as a sym in dbgfile (again with its internal name)
but
int main{
static int foo;
}
or
int main{
#pragma static-locals(on)
int foo;
}
They both generate internal symbols (M0001) that are propagated to the dbgfile but there is no way to match the name in the c code with the name in the C file
THe obvious solution seems to be to change the symbol name to be main_foo
rather than M0001
. This will, however, break any code that is reading the dbgfile and expecting to see M0001. So an alternative would be
main_foo:
M0001:
.res 2,$00
There can be multiple static locals with the same identifier in the same function:
int main()
{
static int foo;
{
static int foo; /* This shadows the previous static local 'foo' */
}
}
So the name mangling has to be a bit more complex.
There can be multiple static locals with the same identifier in the same function:
int main() { static int foo; { static int foo; /* This shadows the previous static local 'foo' */ } }So the name mangling has to be a bit more complex.
Something that'd help debugging for auto variables, (the ones that get M0001 symbols with no csym), could be to have
foo_M0001, foo_M0002 as identifiers.
I gave a look at how it could be done and still, it seems complicated.