> From: Keith Marshall <keith****@users*****> > Date: Sat, 22 Dec 2018 09:11:22 +0000 > > > Does that mean these symbols will only be resolved in Java programs, > > and are provided only for Java? > > I don't know. I do note that the original source file was contributed > by Danny Smith, who hasn't been an active participant for several years > now, AFAIK; perhaps someone else among the GCC developers could clarify? > I've never observed any issue, relating to either of these symbols, but > if you can formulate a minimal failing test case, perhaps it would be > worthwhile to submit a GCC bug report? The only issue about these unresolved symbols I know of is that it trips GDB if you happen to step out of the 'main' function. These unresolved symbols are one factor that causes GDB to hit an internal error; the other factor is that the function __mingw_CRTStartup, which I believe is compiled into crt1.o, doesn't have its symbol in the symbol table of the MinGW binaries (is there any reason for that, btw?). So, when one steps out of 'main', GDB attempts to find the function where the PC value lives by walking the symbol table, and finds these unresolved symbols with address of zero, because they are the only .text symbols below the value of PC. You can see more details in this discussion on the GDB mailing list: https://www.sourceware.org/ml/gdb-patches/2018-12/msg00176.html So, this doesn't seem to be a GCC issue, at least not directly, as these symbols are never accessed in a C/C++ program, so it doesn't matter they didn't get resolved. It's a GDB issue, which will most probably be resolved soon. Thanks.
Fork