dbgfile contains no reference to static locals

[pm100]

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

[acqn]

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.

[colinleroy]

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.