When I first heard about it, it sounded like a great feature—a c++ REPL. However, it cannot call STL functions or methods, and has a whole lot of other issues. This question also applies to conditional breakpoints.
Is it still an experimental feature, or have the developers just dropped it?
Example:
(lldb) p iterator->aField
error: call to a function 'std::__1::__wrap_iter<aClass const*>::operator->() const' ('_ZNKSt3__111__wrap_iterIPK8aClassEptEv') that is not present in the target
error: 0 errors parsing expression
error: The expression could not be prepared to run in the target
At present, there's no good way for the debugger to generate methods of template specializations for which the compiler only emitted inlined versions. And the debugger can't call inlined methods.
Here's one limited trick (though it requires C++11) that you can use to force the compiler to generate full copies of the relevant template class so that there are functions the debugger can call. For instance, if I put:
template class std::vector<int>;
in my source code somewhere, the compiler will generate real copies of all the functions in the int specialization of std::vector. This obviously isn't a full solution, and you should only do this in debug builds or it will bloat your code. But when there are a couple of types that you really call methods on, its a useful trick to know.
You mention a "whole lot of other issues". Please file bugs on any expression parser issues you find in lldb, either with the lldb bugzilla: https://llvm.org/bugs, or Apple's bug reporter: http://bugreporter.apple.com. The expression parser is under active development
Related
In my code (either C or C++; let's say it's C++) I have a one-liner inline function foo() which gets called from many places in the code. I'm using a profiling tool which gathers statistics by line in the object code, which it translates into statistics by using the source-code-line information (which we get with -g in clang or GCC). Thus the profiler can't distinguish between calls to foo() from different places.
I would like the stats to be counted separately for the different places foo() get called. For this to happen, I need the compiler to "fully" inline foo() - including forgetting about it when it comes to the source location information.
Now, I know I can achieve this by using a macro - that way, there is no function, and the code is just pasted where I use it. But that wont work for operators, for example; and it may be a problem with templates. So, can I tell the compiler to do what I described?
Notes:
Compiler-specific answers are relevant; I'm mainly interested in GCC and clang.
I'm not compiling a debug build, i.e. optimizations are turned on.
How can I force the inlining of a function, but define it in a C++ file ?
This is a question that's been asked in the past, for example here: Moving inline methods from a header file to a .cpp files
The answers there, in short, go as follows: "inline used to mean [remove function call overhead at the expense of .text size], now it means [relax ODR], so don't use inline for anything that's not ODR related, the compiler knows better".
I'm aware of that, however in my somewhat exotic case, I don't care about performance.
I'm programming an embedded device and, should someone break through the other layers of security, I want to make it as obnoxious as possible to reverse engineer this part of the code, and one thing this implies is that I don't want function calls (that aren't called numerous times anyway) to expose the function boundaries, which are natural delimitations of pieces of code that achieve something on their own.
However, I would also like to keep my code orderly and not have code in my header files.
I see that I can use __attribute((force_inline)) to force inlining, but then I get warnings if those functions don't have an inline attribute too: warning: always_inline function might not be inlinable [-Wattributes]
Suppressing the attributes warning is an option, but I'd rather only take it once I'm sure there are no clean way to do this.
Hence the question: how can I have a forcibly inlined function whose declaration is in a header, but definition is in a source file, without suppressing all attributes warnings ? Is that impossible ?
Inlining can only be asked. Sometimes a bit forcefully. But you can never guarantee that the function WILL be inlined finally - because reasons, sometimes quite obscure ones.
Here what's MSVC documentation says (I've highlighted the important parts):
The compiler treats the inline expansion options and keywords as suggestions. There's no guarantee that functions will be inlined. You can't force the compiler to inline a particular function, even with the __forceinline keyword. When compiling with /clr, the compiler won't inline a function if there are security attributes applied to the function.
C++ standard says:
No matter how you designate a function as inline, it is a request that the compiler is allowed to ignore: the compiler might inline-expand some, all, or none of the places where you call a function designated as inline.
GCC documentation is a bit less crystal-clear about non-inlinable functions, but cases exists anyway.
The only "real" way to force inlining is quite ugly, since it rely on inlining it before compilation... Yeah, old-style preprocessor macros. The Evil Itself. Or by using a dirty hack with a #include replacing the function call (and inserting C++ code instead)... It may be a bit safer than a macro, regarding double evaluations, but other side-effects can be even worse since it must rely on "global" variables to work.
Does it worth the pain? Probably not. In particular for "obfuscation", because it won't be as "secure" as you think it will be. Yes, an explicit function call is easier to trace. But it won't change anything: reverse engineering don't rely on that to be done. In fact, obfuscation is near never a good (or even working...) solution. I used to think that... a long, very long time ago. I proved to myself that it was near useless. On my own "secured" code. Breaking the code took me much less time than it took me to "protect" it...
When I wanted to alter the execution of the program I am debugging by resizing a vector, but I got an error:
(lldb) expression std_vector_foo.resize(1)
error: Couldn't lookup symbols:
std::vector<string_id<mtype>, std::allocator<string_id<mtype> > >::resize(unsigned long)
Strangely enough the following runs fine:
expression std_vector_foo.reserve(1)
There are two ways to work around the absence of template methods that you want to call.
The most straightforward - if it works for you - is to turn on building the "stl module" for use in the expression parser by putting:
settings set target.import-std-module true
in your ~/.lldbinit. This will cause lldb to build a "clang module" for the stl libraries, from which lldb can build needed specializations on demand. This is, however, a fairly new feature, and was quite tricky to get working, so YMMV... I don't know if the GNU STL is modularizable, so it may only work with a recent version of the clang STL. ""Modules" turns out to be a highly overloaded term; in this context it means the clang feature:
https://clang.llvm.org/docs/Modules.html
If you do find problems with this, please file bugs with http://bugs.llvm.org.
The brute force way to make these methods available if this doesn't work is to put the equivalent of:
template class std::vector<string_id<mtype>>;
for whatever type you were trying to access the methods of into one of your source files. That forces the compiler to emit a complete version of this class specialization, leaving you with methods you can call. Of course, this will also bloat your code and you have to do it specialization by specialization, so it isn't a general solution. Still, it's a useful trick to keep in your back pocket.
Situation
This is a question about debugging. I have installed the GDB pretty printers for the standard library, but I find that they do not work correctly under many circumstances. For instance, debugging a piece of code with the following declaration:
std::map<int, int> foo;
I've compiled with -O0 -ggdb3, so I expected to have no trouble examining foo, and if I manually examine the structures, I experience no issues. However, the STL pretty printers do not work, because GCC seems to be omitting type information about nested types that my program does not explicitly instantiate.
For example, if I run the following command in GDB:
p foo.begin()
I see the following error message:
Python Exception <class 'gdb.error'> No type named
std::_Rb_tree_iterator<std::pair<int const, int> >::_Link_type.
This missing typename is an inner typedef, defined inside std::map::iterator. It's implementation dependent standard library support code, so it's not cross platform (or even guaranteed to continue existing between different versions of the implementation on the same platform).
However, if I declare something involving that type in the program, the pretty printer will work correctly.
std::_Rb_tree_iterator<std::pair<int const, int> >
::_Link_type *dummy = NULL;
Question
So, how do I instruct GCC not to remove the definitions for types in situations such as this, so they remain available to the debugger? Given that the STL implementation is not cross platform, a hacky workaround like declaring a bunch of dummy variables with a preprocessor macro does not seem like a scalable solution. Is there a flag I can pass to GCC to force recursive inclusion of template types? Or does GCC not support this at all? Has anyone else faced this problem and solved it?
Author's Note
GDB pretty printing is broken in GDB 7.7.1 (the most recent version in the ubuntu 14.04 repos as of the time of this writing) and cannot print pointers properly. Those looking at answering this question may find it useful to know that this is a known problem and that a bug has already been filed.
So, how do I instruct GCC not to remove the definitions for types in situations such as this, so they remain available to the debugger?
I don't believe there is any way to instruct GCC to emit debug info for types that are not present in your program.
It is however a very strange program that instantiates std::map, but never uses any of its iterator-using methods.
if I declare something involving that type in the program
There should be no need to do that. Simply calling m.begin() or having a range for loop over the map somewhere in the program is enough to instantiate the iterator type.
We have several C++ functions that will be implemented in phase 2 of our project that are part of the public interface or their respective classes and modules. Because they are part of the public interface, we think they should be present, at least in the headers, during phase 1 so that we are still thinking about them as we implement the rest of the classes. However, since they are unimplemented, we want no one to call them. We would like this check to occur at compile time, to ensure correctness.
My desires are:
Compile time (could be an error or warning; warnings are better because they are more flexible - we can selectively turn them off)
Works on G++4.8.1 and doesn't kill the build under Visual Studio 2013 (we use Visual Studio/VisualAssistX only as an editor but the refactoring tools don't work without building)
Not too hard to understand what was done and why
Functions are present in class documentation (we can include some \warning not implemented in phase 1 notation for doxygen to pick up)
I am considering three options:
A belt and suspenders approach of marking them as deprecated (which will generate a warning) and throwing a custom exception - this is almost what I want except the compiler warning that it is "deprecated" is opposite of the real situation: a deprecated method works now but won't work later; this method will work later but does not work now
Another answer tells how to forbid using a function while still having it exist - this is good but unreadable and hard to search for. Plus, it is a compile-time error - we can't just let some functions call it if we change our minds - it is all or nothing. And making every unimplemented function a template makes me wonder if the trick will always work. For example, virtual functions can't be templates.
Just putting them in as a comment - Keeps people from calling them, but they also don't show up in auto-generated documentation (and we can't decide later to have selective calling)
Is there a better way? And if not is there a reason to prefer the template or comment options over the deprecated option?
As alternative:
You can just declare them without definition, so you get link error.
You may then provide a library not_yet_implemented with empty definition to allow the premature usage of these functions.
or
Mark you method deleted: = delete, eventually by wrapping that in a macro
#define NOT_YET_IMPLEMENTED = delete