for the below case :
extern void sharedLibTestLibRtn (int arg);
extern int testExt;
int main (void)
we don't see the debug-info for "testExt" i.e no DW_AT_type entry for
extern symbol ,where gcc has the same .
we are fixing the same in clang as compatibility with gcc .
before we start our analysis on DIBuilder in clang ,any inputs here
will be appreciated .
Any idea why this is important compared to function declarations that I don’t think any compiler emits (declarations of called but not defined non-member functions)?
I imagine in the function case, it’s assumed that the function is defined elsewhere and the debug info for that definition will be available.
Why not the same with variables?
(admittedly, when we employ the “debug info is in another file” assumption, that should be done under -fno-standalone-debug - but I’m not sure how far we should take that assumption. Should we have debug info for declarations of functions?)
There’s currently at least some code that supports emitting function declarations (for member functions) but not for variables (static member variables are ‘members’ rather than ‘variables’)
I think emitting “testExt” as an external declaration (what gcc does) doesn’t do much for the debugger; being a declaration, it has no location, and so you can’t do things like examine its value, unless you find the symbol in the defining CU first.
I don’t see a real “compatibility with gcc” argument here. Is there some behavior of some consumer that is affected by this?
We have the problem with gdb ,where testExt is defined in shared library and break in main and try “pt testExt” it say no debug info found.
Is there much value in being able to print the type of a variable without being able to otherwise interact with it?