For VS2008 (C++) generated linker map files, what does the symbol "__unwind$" mean? I have a good chunk of them in the linker map file for my app.
I have a log which says a crash happens at a particular offset say 'x'. When I look at the linker map for this offset, I find this __unwind$41357 corresponding to the offset.
Also generally is there any reference to understand the file format of linker map files?
"Unwinding" is happens with a stack when an exception is thrown. The __ prefix indicates a compiler-generated symbol. So, based on the description, you get a crash between a throw and a catch. My assumption is that the destructors called are called from the __unwind$ functions. An inlined destructor wouldn't have its own stackframe, so it would show up in the calling __unwind$ function.
Only a guess, but I would say it is part of the code that handles stack unwinding when an exception is thrown.
Related
I inherited a C++ project with a function defined like so:
void myDoc::parseDoc(string& path) throw(docError);
The parseDoc function calls a library that throws libError, and the main function that calls parseDoc catches both docError and libError and logs them. parseDoc doesn't throw any exceptions itself, but I would've expected the libErrors from the library to still get caught by main. They don't - I just get a core dump with nothing useful on the stack.
I tried various changes to parseDoc. Some of them get libError passed up the chain. and some don't:
catch libError and rethrow it - doesn't work
catch libError and copy it to a docError and throw that - works
specify throw(docError, libError) and not catch anything - works
remove the throw() from the function definition and not catch anything - works
So my question is - does adding a throw(docError) to this function definition specifically prevent other exceptions from being passed up the stack to the caller? If so, why would anyone want to do that? And if not specifying that a function throws exceptions just works the way I always thought exceptions were supposed to work, what's the point of the throw(e) specification in the first place?
Yes, a throw specification does not allow any exceptions except the specified to escape the function.
As for why anyone would want that, the idea is documentation, showing exactly which exceptions the function will throw.
However, in reality, the concept proved to be so useless that throw specifications were (or will be, not sure about the exact status) actually removed in a newer version of C++. So the correct action to take is number 4, removing the specification.
Does the order of parsing effects the order of functions in the import table
(i.e. first function encountered would be first in the import table?) or is it something else ?
Thanks!
EDIT
I'm using Visual Studio, but an answer about other compilers would be great as well!
The compiler has nothing to do with it, the linker creates that table. There is no preset order, simply the order in which the linker encounters exports in the object files. You can make it predictable with a .def file.
There is no real point to it, the location of the export in the table doesn't affect anything. The table entry is always located by ordinal or name, never position. A GetProcAddress() micro-optimization is one you'll never see back in practice, disk I/O overhead blows it away.
Depends. Dynamic linking and therefore DLLs and IATs are not part of standard C++ but an extension many compilers implement. In short, if and how they do it is compiler specific. Maybe the compiler you are using has something about it in the docs.
sooner or later when programming in C/C++ everyone will face the "undefined reference error".
Often this is caused by missing libraries and most of those errors are fixed within seconds by linking against the missing libraries.
However, when for instance one uses templates with seperate files for declaration and implementation, one may get undefined reference caused by "unintended" template instantiation. Unfortunately, all information we now get is an instance of "undefined reference error", without possible hints for the cause such as line numbers of the callers, etc.
What I am curious about:
Is there an easy way to spot the actual sourcecode line(s) that calls the function/the template causing the undefined reference error?
As I mentioned in my answer to this question, whether or not it's straightforward to get a line number causing the link error depends on whether the compiler emitted all the necessary information.
To begin with, these are the cases I've run into that lead to the behavior you're seeing:
The compiler emitting faulty debug info (solaris studio 12.3 with debugging/optimizations under certain circumstances)
A destructor executing for an object going out of scope
Code inserted by the compiler:
stack protector
sanitizers
other tools that instrument code either for debugging or profiling
What I'll suggest for tracking it down may help if you have a link error resembling:
asdf.o: In function `whatever':
asdf.o(.text+0x1238): undefined reference to `fdsa'
... because at the very least you have an address to work with.
First, try addr2line:
~ addr2line -e asdf.o 0x1238
# If it works, you'll get:
asdf.cc:N
# If it doesn't work, you'll get:
??:?
Failing that, try objdump:
~ objdump --dwarf=decodedline asdf.o
asdf.o: file format elf64-x86-64
Decoded dump of debug contents of section .debug_line:
CU: asdf.cc:
File name Line number Starting address
asdf.cc 1 0x1234
asdf.cc 3 0x1254
asdf.cc 5 0x1274
In the completely fabricated example I've given here there isn't an entry in .debug_line corresponding to 0x1238 (the address in the linker error), so it could be compiler magic (eg extra code added by something like stack protector or a sanitizer), or hopefully it's related to whatever is happening on lines 1/3 since the address is between those two lines.
If that doesn't give you enough to go on: when I wanted a little more to go on I did the following:
Insert a link flag to stop it from demangling to get the mangled symbol
Recompile the object file, but have it generate assembly instead
Search the assembly for the mangled symbol
Assuming the assembly is annotated well enough it shouldn't be terribly hard to correlate the missing symbol + info from objdump + the assembly and at least get a fix on the line of code to start the rest of your search (assuming you still have more rabbit holes to go down as is often the case with STL).
Here's what i did:
I changed a .h file from
SomeObj* getCacheObj( int i = 0 );
to
SomeObj* getCacheObj( int i );
SomeObj* getCacheObj();
I recompiled the code (no problems), the changes went to somelib.so (one of many so files). I then replaced the old so on the equipment with this one and got the folowing error when loading the so:
undefined symbol: _ZN13KeypathHelper11getCacheObjEv
Now the strange part is that I've been told this class is only used in this so file (How can I make sure?). I am not that experienced and not sure how to investigate. Any suggestions are welcome.
Update
This particular problem was caused because another so file was using the KeypathHelper class and I only replaced the one containing it. The way I found out which other so needed to be updated was by greping all so's for KeypathHelper.
The _ZN13KeypathHelper11getCacheObjEv symbol is a mangled name for KeypathHelper::getCacheObj() (you can easily translate using c++filt, for example). Given that you have only added a method and whatever is loading the shared object cannot find it makes me think that you either haven't updated the shared object or forgot to provide a definition for KeypathHelper::getCacheObj() (in other words — implement the method).
In order to investigate, you have to see what is failing to resolve the symbol. Usually, developers have a sense for it. Say, if a binary XXX cannot load library YYY due to unresolved symbol, then XXX is using it and it does not appear to be in YYY (or anywhere else for that matter). If there is no sense for that, one can resort to reading ld.so (8) manual page and debug the dynamic linker by using available means like defining LD_DEBUG.
Also, #PlasmaHH has asked a very good question. If the only change you made was to the header file, then you must know that a single function/method with a default value for a parameter is not the same as as two functions/methods where one has a parameter and one does not.
As for your second question about how to make sure that symbol in a shared object is not being used outside — you have to change the symbol visibility so that nobody from the outside is able to link/resolve/use the symbol. For example, see GCC Visibility.
Hope it helps. Good Luck!
Whilst compiling with avr-gcc I have encountered linker errors such as the following:
undefined reference to `__cxa_pure_virtual'
I've found this document which states:
The __cxa_pure_virtual function is an error handler that is invoked when a pure virtual function is called.
If you are writing a C++ application that has pure virtual functions you must supply your own __cxa_pure_virtual error handler function. For example:
extern "C" void __cxa_pure_virtual() { while (1); }
Defining this function as suggested fixes the errors but I'd like to know:
what the purpose of this function is,
why I should need to define it myself and
why it is acceptable to code it as an infinite loop?
If anywhere in the runtime of your program an object is created with a virtual function pointer not filled in, and when the corresponding function is called, you will be calling a 'pure virtual function'.
The handler you describe should be defined in the default libraries that come with your development environment. If you happen to omit the default libraries, you will find this handler undefined: the linker sees a declaration, but no definition. That's when you need to provide your own version.
The infinite loop is acceptable because it's a 'loud' error: users of your software will immediately notice it. Any other 'loud' implementation is acceptable, too.
1) What's the purpose of the function __cxa_pure_virtual()?
Pure virtual functions can get called during object construction/destruction. If that happens, __cxa_pure_virtual() gets called to report the error. See Where do "pure virtual function call" crashes come from?
2) Why might you need to define it yourself?
Normally this function is provided by libstdc++ (e.g. on Linux), but avr-gcc and the Arduino toolchain don't provide a libstdc++.
The Arduino IDE manages to avoid the linker error when building some programs because it compiles with the options "-ffunction-sections -fdata-sections" and links with "-Wl,--gc-sections", which drops some references to unused symbols.
3) Why is it acceptable to code __cxa_pure_virtual() as an infinite loop?
Well, this is at least safe; it does something predictable. It would be more useful to abort the program and report the error. An infinite loop would be awkward to debug, though, unless you have a debugger that can interrupt execution and give a stack backtrace.