at the moment, i'm inserting variables into the beginning of block scope using CreateEntryBlockAlloca:
template <typename VariableType>
static inline llvm::AllocaInst *CreateEntryBlockAlloca(BuilderParameter& buildParameters,
const std::string &VarName) {
HAssertMsg( 1 != 0 , "Not Implemented");
};
template <>
inline llvm::AllocaInst *CreateEntryBlockAlloca<double>(BuilderParameter& buildParameters,
const std::string &VarName) {
llvm::Function* TheFunction = buildParameters.dag.llvmFunction;
llvm::IRBuilder<> TmpB(&TheFunction->getEntryBlock(),
TheFunction->getEntryBlock().begin());
return TmpB.CreateAlloca(llvm::Type::getDoubleTy(buildParameters.getLLVMContext()), 0,
VarName.c_str());
}
Now, i want to add Allocas for non-POD types (that might require a destructor/cleanup function at exit). However, it is not enough to add destructor calls at the end of the exit scope block, since it is not clear how to have them be invoked when a regular DWARF exception is thrown (for the purpose of this argument, lets say that exceptions are thrown from Call points that invoke C++ functions which only throw a POD type, so no, in my case, ignorance is bliss, and i would like to stay away from intrinsic llvm exceptions unless i understand them better).
I was thinking that may be i could have a table with offsets in the stack with the Alloca registers, and have the exception handler (at the bottom of the stack, at the invocation point of the JIT function) walk over those offsets on the table and call destructors appropiately.
The thing i don't know is how to query the offset of the Alloca'ed registers created with CreateAlloca. How can i do that reliably?
Also, if you think there is a better way to achieve this, please enlighten me on the path of the llvm
Technical Comment: the JIT code is being called inside a boost::context which only invokes the JIT code inside a try catch, and does nothing on the catch, it just exits from the context and returns to the main execution stack. the idea is that if i handle the unwinding in the main execution stack, any function i call (for say, cleaning up stack variables) will not overwrite those same stack contents from the terminated JIT context, so it will not be corrupted. Hope i'm making enough sense
The thing i don't know is how to query the offset of the Alloca'ed registers created with CreateAlloca. How can i do that reliably?
You can use the address of an alloca directly... there isn't any simple way to get its offset into the stack frame, though.
Why exactly do you not want to use the intrinsic LLVM exceptions? They really are not that hard to use, especially in the simple case where your code never actually catches anything. You can basically just take the code clang generates in the simple case, and copy-paste it.
Edit:
To see how to use exceptions in IR in the simple case, try pasting the following C++ code into the demo page at http://llvm.org/demo/:
class X { public: ~X() __attribute((nothrow)); };
void a(X* p);
void b() { X x; a(&x); }
It's really not that complicated.
Related
I was wondering about a general topic in C/C++.
Let's say we're executing a function A() which calls a function B(), can we be sure that the call of B() in A() will always return "after" the call itself.
In a more general question, which are the possibilities to quit a function ?
The C keywords are (Wikipedia) : auto, break, case, char, const (C89), continue, default, do, double, else, enum (C89), extern, float, for, goto, if, inline (C99), int, long, register, restrict (C99), return, short, signed (C89), sizeof, static, struct, switch, typedef, union, unsigned, void (C89), volatile (C89), while, _Bool (C99), _Complex (C99), _Imaginary (C99).
As far as I know, the one interesting in this topic are :
break/continue : Used in loops or switchs (as I was told by GCC after trying), they can't exit a function.
goto : The scope of labels is restricted by the functions so a goto can't exit a function
return : Can exit a function but always returns to the instruction after the call. We're safe with this one.
The exit()/abort() functions which will end up the application. We won't return to the calling point, but .. we won't return at all.
I think that is for the C language. Do you think there is another way to quit a function and without returning to the calling point ?
In C++, exceptions will obviously not return to the calling point. They will either go to a catch block or reach the calling function, looking for a catch block.
As far as I known, it would be the only case.
Thanks for helping me =)
In standard C (using setjmp/longjmp) and C++ (using exceptions), it is possible to effectively return to marked points closer to the root of the CFG. In effect, a function may never return, but if it does return, it will be to the point following the call.
However, the low-level nature of the setjmp mechanism actually makes it possible to implement coroutines (albeit in a non-portable way). Posix attempted to improve on this situation by mandating makecontext and friends, which allow for explicit stack swapping, but those functions were deprecated in Posix.1-2001 and removed from Posix.1-2008, citing portability issues, with the suggestion that threads be used instead. Nonetheless, there are a number of coroutine libraries in use which use these features to allow C programmers to enjoy the flexibility of coroutines.
In coroutine control flow, while the execution path following a (co)call might be sinuous, it is still the case that a function call either never returns or eventually returns to the immediately following point. However, the low-level nature of the C library facilities makes it possible to implement more complex control flows, in which a given (co)call might, for example, return several times. (I've never seen this particular anomaly implemented in production code, but I can't claim to have seen even a tiny percentage of all production code in the world :) ).
A gcc extension to C allows for the use of "label values", which are pointers to labels in the code. These are real values (of type void *) so they can be passed as arguments to functions. (The gcc manual warns against doing this.) With some reverse-engineering, it would probably be possible to write a function which takes one or more label arguments and uses one of them as a return point. That would clearly be a misuse of the feature, would likely not be either portable nor future-proof, and would almost certainly break any coding standards in existence.
The interesting thing about the C library facilities, as opposed to C++ exceptions which are actually part of the core language, is that they really are functions; in C, as with many programming languages, functions can be called indirectly through function pointers so that it might not be readily computable through static analysis which function is being called at a given call site. So, at least in theory, I'd say all bets are off. But in practice it's probably a safe assumption that a function call will either eventually return to the immediately following point or return to somewhere down the call stack, possibly the operating system environment.
Look up setjmp() and longjmp(). setjmp() records a certain amount of local state at the point it's called. longjmp() will return, potentially across several levels of function, to the point where you called setjmp().
You can use it for a primitive form of exception handling in C. It's very, very rarely used.
You can exit a function with
return
silently at the end of its body (without explicit return in a void function())
an exception
a longjmp()
inline assembly jumping to some address
I remember creating this func when i needed a way to quit a big program without exit
int my_exit()
{
pid_t pid;
int i;
pid = getpid();
i = kill(pid, SIGQUIT);
if (i == -1)
return (-1);
return (0);
}
'Let's say we're executing a function A() which calls a function B(), can we be sure that the call of B() in A() will always return "after" the call itself'. No, because:
'B' may raise an exception that is not caught in 'A'.
'B' may contain an infinite loop.
'B' may make a blocking OS call that never returns.
Consider the following functions:
int main()
{
//statement(s);
func1();
//statement(s);
}
void func1()
{
//statement(s);
func2();
//statement(s);
}
void func2()
{
//statement(s);
}
How does the compiler know where to return to after the func2 has performed all its operations? I know the control transfers to function func1 (and exactly which statement), but how does the compiler knows it? What tells the compiler where to return to?
This is typically implemented using a call stack:
When control is being transfered to a function, the address to return to is pushed onto the stack.
When the function finishes, the address is popped off the stack and used to transfer control back to the callee.
The details are typically mandated by the hardware architecture for which the code is being compiled.
Actually, the compiler doesn't run the code, but the machine does, and when it calls a new function, it stores the address of the next instruction to be executed after the function currently being called on the stack, so that when the function returns it can pop it off back in to the Instruction Pointer (IP) and resume from there.
I've simplified things a bit for the sake of explanation.
When a function is called, the correct return address in the calling function is placed somewhere, usually the stack though the standard does not mandate that, that is used for precisely the purpose of storing the return address.
It is the compiler's duty to ensure that its calling conventions are such that unless something goes wrong (for example, a stack overflow), then the called function knows how to return to the calling function.
The runtime makes use of some thing called as a 'call stack' which basically holds the address of the next statement to call after the function being called is returned. So when a function call is made and before the control jumps to the new instruction address, the next instruction address in the calling function is pushed on to the stack. And this process is repeated for every subsequent call to any function. Now why only a stack? because it's necessary to get back to the point where it left off - which is basically a 'last in first out' behavior and stack is the data structure that does that. You can actually look at this call stack when you are debugging a program in Visual Studio - there's a separate window called 'Call Stack' which shows the entries of the addresses placed in the call stack.
Suppose I have a function foo (in C/C++) that is called from a given software tool.
Function foo is only allowed to write memory that has been allocated by foo or one of the functions called by foo, but not to write to memory that has been allocated by the functions that have been executed before calling foo.
I have the strong suspicion that at some place foo writes to memory it is not allowed to.
Is there a way to systematically debug this behavior? Maybe some fancy flag to valgrind?
The Valgrind manual has some Valgrind functions that your program can call.
It looks like VALGRIND_MAKE_MEM_NOACCESS may be what you want.
You could use a custom allocator (Boost Pool comes to mind) to make sure all your memory that you want to 'protect' is contiguously allocated.
Next, set a hardware breakpoint when any data in that memory region is changed.
I'd write a GDB script that sets a breakpoint on your function, then sets a hardware watch on the memory you suspect is being altered, then continues.
If function foo is modifying that memory the hardware watch will trigger on that instruction doing it.
The GDB script might look like:
break foo
commands
up
watch array
down
continue
end
I didn't test that and it may need tweaking, especially the watch expression. You might be limited to watching only one array element. I believe hardware watchpoints can actually watch only one integer size block: 4 bytes on 32 bit or 8 bytes on 64 bit.
The only way foo() can write to the memory outside its scope is if that memory is global, i.e. extern variable, or if foo() had one or more arguments which were meant to be read only but somehow they got modified.
To verify if the calling arguments are getting modified, you can create a structure to hold the arguments and just before returning compare original with saved arguments.
struct foo_args {
int a;
char *b;
};
void
foo(int a, char *b)
{
struct foo_args args;
args.a = a
args.b = strdup(b);
/* The rest of the foo() code. */
if (args.a != a || strcmp(args.b, b) != 0) {
printf("error - args got modified\n");
}
free(args.b);
}
If the above doesn't catch it, then the likely scenario is that either global, stack or heap memory is getting corrupted.
To have valgrind run the tool may not be practical, in which case you will need to create a 'wrapper' for foo() and ensure using valgrind or something similar that it is not doing what it is not supposed to do. The other option is to use a debugging library that tracks/monitors memory usage and flags memory errors as they occur.
I am writing a program using gcc in c++. On dec. 5th I posted a question because of a weird problem ( https://stackoverflow.com/a/8392854/837803 ). When a software exception leaves a function declared with no 'throw' specifications like this:
int foo();
or this:
int foo() throw();
gcc-generated code will crash.
I want to tell gcc that any kind of software exception could leave any function I write. I think it is something like:
int foo() throw(...);
BUT: I don't want to write throw(...) in all function specifications. I realise that my program size will be bigger, but that is not a problem for this case. Also, I have read that the behaviour of gcc that I am suggesting, is an ANSI violation. But that is no problem either.
Among the many, many, many command-line options of gcc, there must be one that I am looking for, but I haven't found it yet.
What is the option I am looking for?
I take exception to this:
gcc-generated code will crash.
This is just plain wrong.
A function declared like this:
void func1();
If you throw an exception it will cause the stack to unwind upto an appropriate catch. IF there is no appropriate catch the program exits (weather the stack unwinds in this case is implementation defined (thus put a catch all in main)).
A function declared like this:
void func2() throw(); // ie no throw.
If an exception escapes this function then unexpected() is called. The default action of unexpected is to call abort() which causes the program to exit (Note: you can replace unexpected with a user defined function but it has to either exit or throw an alternative exception that can pass the throw specification (in this case that is not possible)).
The behavior you want is the default behavior (with no throw specification). Throw specifications were an experiment that failed and have thus been deprecated. You should not be using them anyway (apart from no-throw).
So you can get normal working code with exceptions if you define your functions like this:
void func3(); // Exceptions work fine.
But it is best to put a catch in main()
int main()
{
try
{
// DoWork
}
catch(std::exception const& e) // We can print a good error message with these
{
log(e.what());
throw; // Not much you can do so re-throw for the OS.
}
catch(...) // Catch all other exceptions.
{
log("Unknown Exception");
throw; // Not much you can do so re-throw for the OS.
}
// Catching forces the stack to unwind all the way to main()
// Otherwise it is implementation defined whether it unwinds.
}
It will depend on your compiler. With gcc default settings you can just throw stuff without having throw(...) in the prototype.
I use throw declarations in the prototype when I want to reduce the amount of throwable 'things'. So int myfunc() throw(string) will only allow strings (or a derived class of string to be thrown).
The following assumes that you are throwing an exception of the type as outlined in this question.
Your exception type doesn't work.
In throw_exception, we have this line:
text l_message;
I don't know what a text is, but I'll assume it is a string-like class. I will similarly assume that test::_char is just a fancy way of saying char.
So we have this stack object l_message which is of type text. Later, we have this line:
throw exc((const text::_char *)l_message);
Since you did not deign to provide us with a definition of text, again, I must make an assumption. I assume that text has an operator text::_char* defined for it which returns a pointer to a C-style string representing the stored string data, which is NULL-terminated.
Only there's one problem: that pointer is owned by l_message.
The moment l_message falls off the stack, the pointer returned by l_message disappears. That would be fine... if the class exc actually copied that string into an internal buffer. But it doesn't. It just stores a pointer.
A pointer which no longer points to valid memory. That's not a good idea.
An exception needs to be self-contained. It should own all of the memory it needs to do whatever it is supposed to do.
Also, you did not properly derived from std::exception. Specifically, you have to overload the virtual const char* what() const throw() method. Then again, I'm surprised it let you compile your code without it.
I am not very good in multithreading programming so I would like to ask for some help/advice.
In my application I have two threads trying to access a shared object.
One can think about two tasks trying to call functions from within another object. For clarity I will show some parts of the program which may not be very relevant but hopefully can help to get my problem better.
Please take a look at the sample code below:
//DataLinkLayer.h
class DataLinkLayer: public iDataLinkLayer {
public:
DataLinkLayer(void);
~DataLinkLayer(void);
};
Where iDataLinkLayer is an interface (abstract class without any implementation) containing pure virtual functions and a reference (pointer) declaration to the isntance of DataLinkLayer object (dataLinkLayer).
// DataLinkLayer.cpp
#include "DataLinkLayer.h"
DataLinkLayer::DataLinkLayer(void) {
/* In reality task constructors takes bunch of other parameters
but they are not relevant (I believe) at this stage. */
dll_task_1* task1 = new dll_task_1(this);
dll_task_2* task2 = new dll_task_2(this);
/* Start multithreading */
task1->start(); // task1 extends thread class
task2->start(); // task2 also extends thread class
}
/* sample stub functions for testing */
void DataLinkLayer::from_task_1() {
printf("Test data Task 1");
}
void DataLinkLayer::from_task_2() {
printf("Test data Task 2");
}
Implementation of task 1 is below. The dataLinLayer interface (iDataLinkLayer) pointer is passed to the class cosntructor in order to be able to access necessary functions from within the dataLinkLayer isntance.
//data_task_1.cpp
#include "iDataLinkLayer.h" // interface to DataLinkLayer
#include "data_task_1.h"
dll_task_1::dll_task_1(iDataLinkLayer* pDataLinkLayer) {
this->dataLinkLayer = pDataLinkLayer; // dataLinkLayer declared in dll_task_1.h
}
// Run method - executes the thread
void dll_task_1::run() {
// program reaches this point and prints the stuff
this->datalinkLayer->from_task_1();
}
// more stuff following - not relevant to the problem
...
And task 2 looks simialrly:
//data_task_2.cpp
#include "iDataLinkLayer.h" // interface to DataLinkLayer
#include "data_task_2.h"
dll_task_2::dll_task_2(iDataLinkLayer* pDataLinkLayer){
this->dataLinkLayer = pDataLinkLayer; // dataLinkLayer declared in dll_task_2.h
}
// // Run method - executes the thread
void dll_task_2::run() {
// ERROR: 'Access violation reading location 0xcdcdcdd9' is signalled at this point
this->datalinkLayer->from_task_2();
}
// more stuff following - not relevant to the problem
...
So as I understand correctly I access the shared pointer from two different threads (tasks) and it is not allowed.
Frankly I thought that I will be able to access the object nevertheless however the results might be unexpected.
It seems that something goes terribly wrong at the point when dll_task_2 tries to call the function using pointer to the DataLinkLayer. dll_task_2 has lower priority hence it is started afterwards. I don't understand why i still cannot at least access the object...
I can use the mutex to lock the variable but I thought that the primary reason for this is to protect the variable/object.
I am using Microsoft Visual C++ 2010 Express.
I don't know much about multithreading so maybe you can suggest a better solution to this problem as well as explain the reason of the problem.
The address of the access violation is a very small positive offset from 0xcdcdcdcd
Wikipedia says:
CDCDCDCD Used by Microsoft's C++ debugging runtime library to mark uninitialised heap memory
Here is the relevant MSDN page.
The corresponding value after free is 0xdddddddd, so it's likely to be incomplete initialization rather than use-after-free.
EDIT: James asked how optimization could mess up virtual function calls. Basically, it's because the currently standardized C++ memory model makes no guarantees about threading. The C++ standard defines that virtual calls made from within a constructor will use the declaring type of the constructor currently being run, not the final dynamic type of the object. So this means that, from the perspective of the C++ sequential execution memory model, the virtual call mechanism (practically speaking, a v-table pointer) must be set up before the constructor starts running (I believe the specific point is after base subobject construction in the ctor-initializer-list and before member subobject construction).
Now, two things can happen to make the observable behavior different in a threaded scenario:
First, the compiler is free to perform any optimization that would, in the C++ sequential execution model, act as-if the rules were being followed. For example, if the compiler can prove that no virtual calls are made inside the constructor, it could wait and set the v-table pointer at the end of the constructor body instead of the beginning. If the constructor doesn't give out the this pointer, since the caller of the constructor also hasn't received its copy of the pointer yet, then none of the functions called by the constructor can call back (virtually or statically) to the object under construction. But the constructor DOES give away the this pointer.
We have to look closer. If the function to which the this pointer is given is visible to the compiler (i.e. included in the current compilation unit), the the compiler can include its behavior in the analysis. We weren't given that function in this question (the constructor and member functions of class task), but it seems likely that the only thing that happens is that said pointer is stored in a subobject which is also not reachable from outside the constructor.
"Foul!", you cry, "I passed the address of that task subobject to a library CreateThread function, therefore it is reachable and through it, the main object is reachable." Ah, but you do not comprehend the mysteries of the "strict aliasing rules". That library function does not accept a parameter of type task *, now does it? And being a parameter whose type is perhaps intptr_t, but definitely neither task * nor char *, the compiler is permitted to assume, for purposes of as-if optimization, that it does not point to a task object (even if it clearly does). And if it does not point to a task object, and the only place our this pointer got stored is in a task member subobject, then it cannot be used to make virtual calls to this, so the compiler may legitimately delay setting up the virtual call mechanism.
But that's not all. Even if the compiler does set up the virtual call mechanism on schedule, the CPU memory model only guarantees that the change is visible to the current CPU core. Writes may become visible to other CPU cores in a completely different order. Now, the library create thread function ought to introduce a memory barrier that constrains CPU write reordering, but that fact that Koz's answer introducing a critical section (which definitely includes a memory barrier) changes the behavior suggests that perhaps no memory barrier was present in the original code.
And, CPU write reordering can not only delay the v-table pointer, but the storage of the this pointer into the task subobject.
I hope you have enjoyed this guided tour of one small corner of the cave of "multithreaded programming is hard".
printf is not, afaik, thread safe. Try surrounding the printf with a critical section.
To do this you InitializeCriticalSection inside iDataLinkLayer class. Then around the printfs you need an EnterCriticalSection and a LeaveCriticalSection. This will prevent both functions entering the printf simultaneously.
Edit: Try changing this code:
dll_task_1* task1 = new task(this);
dll_task_2* task2 = new task(this);
to
dll_task_1* task1 = new dll_task_1(this);
dll_task_2* task2 = new dll_task_2(this);
Im guessing that task is in fact the base class of dll_task_1 and dll_task_2 ... so, more than anything, im surprised it compiles ....
I think it's not always safe to use 'this' (i.e. to call a member function) before the end of the constructor. It could be that task are calling member function of DataLinkLayer before the end of DataLinkLayer constructor. Especially if this member function is virtual:
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.7
I wanted to comment on the creation of the DataLinkLayer.
When I call the DataLinkLayer constructor from main:
int main () {
DataLinkLayer* dataLinkLayer = new DataLinkLayer();
while(true); // to keep the main thread running
}
I, of coruse, do not destruct the object, this is first. Now, inside the DataLinkLayer cosntructor I initialize many (not only these two tasks) other objects isntances and pass to most of them dataLinkLayer pointer (using this). This is legal, as far as I am concerned. Put it further - it compiles and runs as expected.
What I became curious about is the overall design idea that I am following (if any :) ).
The DataLinkLayer is a parent class that is accessed by several tasks which try to modify it parameters or perform some other processing. Since I want that everything remain as decoupled as possible I provide only interfaces for the accessors and encapsulate the data so that I don't have any global variables, friend functions etc.
It would have been a pretty easy task to do if only multithreading would not be there. I beleive I will encounter many other pitfalls on my way.
Feel free to discuss it please and merci for your generous comments!
UPD:
Speaking of passing the iDataLinkLayer interface pointer to the tasks - is this a good way to do it? In Java it would be pretty usual thing to realize a containment or so called strategy pattern to make things decoupled and stuff. However I am not 100% sure whether it is a good solution in c++... Any suggestions/commnets on it?