Is there anyway I can load a shared library into shared memory in a process so that some other process can simply map that shared memory (to the same address) and simply invoke functions? I understand that the external in the shared library need to have an additional jump into process-specific memory locations to call into appropriate functions (like elf plt). But, is such a thing viable with today's tools.
But, is such a thing viable with today's tools.
Not with today's tools, nor ever.
Sure, if your shared library has completely self-contained functions, then it will work. But the moment your library references external data or functions, you will crash and burn.
I understand that the external in the shared library need to have an additional jump into process-specific memory locations to call into appropriate functions
I don't think you understand. Let's consider an example:
void *foo() { return malloc(1); }
When this is built into a shared library on Linux, the result is:
0x00000000000006d0 <+0>: mov $0x1,%edi
0x00000000000006d5 <+5>: jmpq 0x5c0 <malloc#plt>
and
Dump of assembler code for function malloc#plt:
0x00000000000005c0 <+0>: jmpq *0x200a5a(%rip) # 0x201020 <malloc#got.plt>
0x00000000000005c6 <+6>: pushq $0x1
0x00000000000005cb <+11>: jmpq 0x5a0
So the question is: where will jmpq *0x200a5a(%rip) go in the second process. Answer: one of two places.
If the first process has already called malloc (very likely), then the jmpq will go to address of malloc in the first process, which is exceedingly unlikely to be the address of malloc in the second process, and more likely to be unmapped, or be in the middle of some data. Either way, you crash.
If the first process has not yet called malloc, then the jmpq in the second process will jump to address of the runtime loader (ld-linux.so.2 or similar on Linux, ld.so on Solaris) resolver function. Again, that address is very unlikely to also be the address of the resolver in the second process, and if it's not, you crash.
But it gets worse from here. If by some improbable magic you ended up actually calling malloc in the second process, that malloc is itself very likely to crash, because it will try to use data structures it has set up previously, using memory obtained from sbrk or mmap. These data structures are present in the first process, but not in the second, and so you crash again.
For a while now I have been a little confused about the role of constant members within a language, such as Java or C. I understand that at the source code level, they prevent certain critical members from being mutated and changed, but when compiled or interpreted, is there any difference between them and variable members at all or are they all just pointers to memory addresses?
I thought that perhaps the compiler/interpreter has to implement something special to allow a variable to be mutable, something it wouldn't have to when handling a constant member (perhaps making execution faster or making it use less memory?), is this true or am I completely up the wrong tree?
The const variable and the variable are not stored in the same place once your code is executed. The constant values will go in the flash memory with your program. The variables will go in the flash too but will then be copied in the ram to be modified as your program runs. Making a variable const makes your computer save time and space by not pushing everything in the ram. When you need to modify it, you will push it into the Ram anyway, but most of the time const variables will not be modified.
This is in addition to the software fact that you might want to prevent your code to modify a value by mistake.
I'm trying to debug my program using Valgrind. I compiled with -g3 -O0 -ggdb. How ever I am unable to see the source code corresponding to the point where Valgrind finds problem. The output just shows the name of the (binary)library.
These addresses are of no interest. They belong to the runtime support code that runs after main and calls destructors of global objects and atexit routines. They do not have any source (that you wrote) associated with them.
You can tell that from their placement between exit and __cxa_finalize in the call stack. No user code could possibly belong there.
Silly question, but do you have the source for that library? If not, and that library wasn't compiled with debugging symbols, valgrind isn't going to decompile the binary and show you source.
Valgrind is complaining about a double free on exit. The line:
Address 0x5980ec0 is 0 bytes inside a block of size 29 free'd
Is pointing you where this memory block was previously freed. Taking into account that this is also in exit I can think of two possible reasons:
Some global and static variables that are been freed (with C++ I've seen this problem when directly assigning two global objects, containing pointers, using default copy constructor. As both pointers refer to same memory address, on exit, this is freed twice).
libslm.so has been loaded by using dlopen, then, on exit, it is closed and can also cause some problems with currently managed memory.
I'm assuming that libslm.so is yours so, I think, in both scenarios is important to know something about lines you marked. Have you checked that the path in the log is the same were you have your libraries with debug information? Is AddrScram linked against these libraries (with same exact path)?
So I am reading from MicroC/OS-II book, but in the section for task stacks I couldn't find exactly what the stack is and most importantly - what is it used for. I know it is not something long and difficult, but I kinda' have to understand it. The book only says how to set the stack size and some other things like this.
So, can somebody explain me in short and simple words what is the task stack and what is it used for, in uC/OS-II ?
In general in the context of a procedural programming language, the stack is where a function/procedure/sub-routine's local variables and return address are stored (in a "stack frame") - the greater the call depth, the more stack frames are stored - one for each function that has not yet returned. That part is true regardless of whether you are using an RTOS such as MicroC/OS-II or not.
In a single threaded environment, only one stack is required, and this is normally provided for you as part of the C runtime environment set-up for example. In a multi-threaded environment, you need a stack for each separate thread of execution, and it is typically up to you to allocate stack space for each thread, or at least to specify its length.
I don't know MicroC/OS-II, but the stack of a task is nearly always the same:
During the execution of a task, it stores data that are required in the current context. This means when a subroutine (method, etc.) is called, a "stack frame" is stored on top of the stack. This stack frame stores local variables of the called subroutine, the return address used when the subroutine is finished, and some other info. When the subroutine returns, the stack frame is deleted. If the subroutine calls another one (or itself recursively), another stack frame is stored on top of the current one.
In contrast to a stack where stored data are deleted in reverse order as the have been stored, a heap stores data a long as their memory is not freed, which can be done in an arbitrary order.
Many processors have a stack pointer, and most of those have instructions that specifically use that stack pointer. The stack pointer is a register that holds an address, not unlike the program counter. The stack is simply memory pointed to by the stack pointer, at a higher level you or the operating system or someone divides the available memory space up for different uses, a little for data a little for program a little for heap (mallocs and frees) and some for the stack. The stack pointer and associated instructions allow code to temporarily allocate some memory. A global variable for example is at least for the life of your program stuck at one memory location. A local variable though only needs a memory location while the function is being executed, when the function returns you dont need that local variable memory (statically defined locals are allocated like globals but only available during that function, so not temporary). You could do a malloc and free in the function to allocate this local memory, or you could simply use the stack. And many/most compilers simply use the stack. In addition to local variables you might need to store the return address, if function a() calls function b() to get from b back to where you were in a you need to return to the next instruction after the call to b(). if B calls c then within the context of b() you need to save the return to a() and now within c() you need to know how to return to b(). And so on. This is architecture and calling convention dependent, some architectures always use the stack for returns, some lean toward using a specific register. When nesting calls though all architectures are going to need to eventually use the stack for the return address, so the stack is used here as well. If function a() calls itself 10 times and has one local integer and the return address lets say it needs 8 bytes of stack per call, so first call moves the stack pointer 8 bytes allocating 8 bytes, the second call another 8 and so on. when you start to hit returns, the the stack pointer moves back 8 bytes, another return another 8 bytes back on the stack pointer.
Now translate that from a single application to multiple applications with the illusion if executing simultaneously (an operating system) for each application/task/procedure/thread/whatever you probably want each of them to have their own stack. This is often quite easy as you just need to save the stack pointer from the prior task and set the stack pointer to the last value from the next task when it was switched out. You can of course get much more complicated and have protection mechanisms so each application can only live within its memory space including stack and heap. and mmus can make it even more complicated by having physical memory chopped up into many pieces and the mmu makes it look like separate pieces are linear within the applications virtual address space. etc.
as nurd_droid pointed out some processors have different stack pointers depending on the mode of the processor. you might have one for user/application mode, then when a system call happens a system/superuser stack pointer, and an interrupt happens an interrupt stack pointer. Some architectures simply have one stack pointer...Some architectures the stack is not in the main memory space the stack and stack pointer are buried in the logic and you dont really see it (often in this case the stack size is quite limited and can roll around on itself or other bad things if you dont manage your stack usage).
Stack is a data structure of type last in first out (LIFO) which is used by procedural languages to do push/pop local variable, CPU registers, return addresses before making a function call or when an interrupt occurs or for preparation of context switches.
Variables, registers are popped out in exactly reverse order when compared to order they are pushed on stack.
Stack can grow upwards or downwards in memory. This is something that will depend upon the micro-controller.
Also, many micro-controllers have multiple stacks.
1) User stack
2) Exception stack or Interrupt stack
If RTOS is used then each process/thread/task will have its own stack. In this case user SP micro-controller register will be reassigned by context switch routine to point to stack for currently active process/thread/task.
Exception stack or Interrupt stack is shared across the system.
When I write a program and tell it int c=5, it puts the value 5 into a little bit of it's memory, but how does it remember which one? The only way I could think of would be to have another bit of memory to tell it, but then it would have to remember where it kept that as well, so how does it remember where everything is?
Your code gets compiled before execution, at that step your variable will be replaced by the actual reference of the space where the value will be stored.
This at least is the general principle. In reality it will be way more complecated, but still the same basic idea.
There are lots of good answers here, but they all seem to miss one important point that I think was the main thrust of the OP's question, so here goes. I'm talking about compiled languages like C++, interpreted ones are much more complex.
When compiling your program, the compiler examines your code to find all the variables. Some variables are going to be global (or static), and some are going to be local. For the static variables, it assigns them fixed memory addresses. These addresses are likely to be sequential, and they start at some specific value. Due to the segmentation of memory on most architectures (and the virtual memory mechanisms), every application can (potentially) use the same memory addresses. Thus, if we assume the memory space programs are allowed to use starts at 0 for our example, every program you compile will put the first global variable at location 0. If that variable was 4 bytes, the next one would be at location 4, etc. These won't conflict with other programs running on your system because they're actually being mapped to an arbitrary sequential section of memory at run time. This is why it can assign a fixed address at compile time without worrying about hitting other programs.
For local variables, instead of being assigned a fixed address, they're assigned a fixed address relative to the stack pointer (which is usually a register). When a function is called that allocates variables on the stack, the stack pointer is simply moved by the required number of bytes, creating a gap in the used bytes on the stack. All the local variables are assigned fixed offsets to the stack pointer that put them into that gap. Every time a local variable is used, the real memory address is calculated by adding the stack pointer and the offset (neglecting caching values in registers). When the function returns, the stack pointer is reset to the way it was before the function was called, thus the entire stack frame including local variables is free to be overwritten by the next function call.
read Variable (programming) - Memory allocation:
http://en.wikipedia.org/wiki/Variable_(programming)#Memory_allocation
here is the text from the link (if you don't want to actually go there, but you are missing all the links within the text):
The specifics of variable allocation
and the representation of their values
vary widely, both among programming
languages and among implementations of
a given language. Many language
implementations allocate space for
local variables, whose extent lasts
for a single function call on the call
stack, and whose memory is
automatically reclaimed when the
function returns. (More generally, in
name binding, the name of a variable
is bound to the address of some
particular block (contiguous sequence)
of bytes in memory, and operations on
the variable manipulate that block.
Referencing is more common for
variables whose values have large or
unknown sizes when the code is
compiled. Such variables reference the
location of the value instead of the
storing value itself, which is
allocated from a pool of memory called
the heap.
Bound variables have values. A value,
however, is an abstraction, an idea;
in implementation, a value is
represented by some data object, which
is stored somewhere in computer
memory. The program, or the runtime
environment, must set aside memory for
each data object and, since memory is
finite, ensure that this memory is
yielded for reuse when the object is
no longer needed to represent some
variable's value.
Objects allocated from the heap must
be reclaimed—especially when the
objects are no longer needed. In a
garbage-collected language (such as
C#, Java, and Lisp), the runtime
environment automatically reclaims
objects when extant variables can no
longer refer to them. In
non-garbage-collected languages, such
as C, the program (and the programmer)
must explicitly allocate memory, and
then later free it, to reclaim its
memory. Failure to do so leads to
memory leaks, in which the heap is
depleted as the program runs, risking
eventual failure from exhausting
available memory.
When a variable refers to a data
structure created dynamically, some of
its components may be only indirectly
accessed through the variable. In such
circumstances, garbage collectors (or
analogous program features in
languages that lack garbage
collectors) must deal with a case
where only a portion of the memory
reachable from the variable needs to
be reclaimed
There's a multi-step dance that turns c = 5 into machine instructions to update a location in memory.
The compiler generates code in two parts. There's the instruction part (load a register with the address of C; load a register with the literal 5; store). And there's a data allocation part (leave 4 bytes of room at offset 0 for a variable known as "C").
A "linking loader" has to put this stuff into memory in a way that the OS will be able to run it. The loader requests memory and the OS allocates some blocks of virtual memory. The OS also maps the virtual memory to physical memory through an unrelated set of management mechanisms.
The loader puts the data page into one place and instruction part into another place. Notice that the instructions use relative addresses (an offset of 0 into the data page). The loader provides the actual location of the data page so that the instructions can resolve the real address.
When the actual "store" instruction is executed, the OS has to see if the referenced data page is actually in physical memory. It may be in the swap file and have to get loaded into physical memory. The virtual address being used is translated to a physical address of memory locations.
It's built into the program.
Basically, when a program is compiled into machine language, it becomes a series of instructions. Some instructions have memory addresses built into them, and this is the "end of the chain", so to speak. The compiler decides where each variable will be and burns this information into the executable file. (Remember the compiler is a DIFFERENT program to the program you are writing; just concentrate on how your own program works for the moment.)
For example,
ADD [1A56], 15
might add 15 to the value at location 1A56. (This instruction would be encoded using some code that the processor understands, but I won't explain that.)
Now, other instructions let you use a "variable" memory address - a memory address that was itself loaded from some location. This is the basis of pointers in C. You certainly can't have an infinite chain of these, otherwise you would run out of memory.
I hope that clears things up.
I'm going to phrase my response in very basic terminology. Please don't be insulted, I'm just not sure how proficient you already are and want to provide an answer acceptable to someone who could be a total beginner.
You aren't actually that far off in your assumption. The program you run your code through, usually called a compiler (or interpreter, depending on the language), keeps track of all the variables you use. You can think of your variables as a series of bins, and the individual pieces of data are kept inside these bins. The bins have labels on them, and when you build your source code into a program you can run, all of the labels are carried forward. The compiler takes care of this for you, so when you run the program, the proper things are fetched from their respective bin.
The variables you use are just another layer of labels. This makes things easier for you to keep track of. The way the variables are stored internally may have very complex or cryptic labels on them, but all you need to worry about is how you are referring to them in your code. Stay consistent, use good variable names, and keep track of what you're doing with your variables and the compiler/interpreter takes care of handling the low level tasks associated with that. This is a very simple, basic case of variable usage with memory.
You should study pointers.
http://home.netcom.com/~tjensen/ptr/ch1x.htm
Reduced to the bare metal, a variable lookup either reduces to an address that is some statically known offset to a base pointer held in a register (the stack pointer), or it is a constant address (global variable).
In an interpreted language, one register if often reserved to hold a pointer to a data structure (the "environment") that associates variable names with their current values.
Computers ultimately only undertand on and off - which we conveniently abstract to binary. This language is the basest level and is called machine language. I'm not sure if this is folklore - but some programmers used to (or maybe still do) program directly in machine language. Typing or reading in binary would be very cumbersome, which is why hexadecimal is often used to abbreviate the actual binary.
Because most of us are not savants, machine language is abstracted into assembly language. Assemply is a very primitive language that directly controls memory. There are a very limited number of commands (push/pop/add/goto), but these ultimately accomplish everything that is programmed. Different machine architectures have different versions of assembly, but the gist is that there are a few dozen key memory registers (physically in the CPU) - in a x86 architecture they are EAX, EBX, ECX, EDX, ... These contain data or pointers that the CPU uses to figure out what to do next. The CPU can only do 1 thing at a time and it uses these registers to figure out what to do next. Computers seem to be able to do lots of things simultaneously because the CPU can process these instructions very quickly - (millions/billions instructions per second). Of course, multi-core processors complicate things, but let's not go there...
Because most of us are not smart or accurate enough to program in assembly where you can easily crash the system, assembly is further abstracted into a 3rd generation language (3GL) - this is your C/C++/C#/Java etc... When you tell one of these languages to put the integer value 5 in a variable, your instructions are stored in text; the assembler compiles your text into an assembly file (executable); when the program is executed, the program and its instructions are queued by the CPU, when it is show time for that specific line of code, it gets read in the the CPU register and processed.
The 'not smart enough' comments about the languages are a bit tongue-in-cheek. Theoretically, the further you get away from zeros and ones to plain human language, the more quickly and efficiently you should be able to produce code.
There is an important flaw here that a few people make, which is assuming that all variables are stored in memory. Well, unless you count the CPU registers as memory, then this won't be completely right. Some compilers will optimize the generated code and if they can keep a variable stored in a register then some compilers will make use of this!
Then, of course, there's the complex matter of heap and stack memory. Local variables can be located in both! The preferred location would be in the stack, which is accessed way more often than the heap. This is the case for almost all local variables. Global variables are often part of the data segment of the final executable and tend to become part of the heap, although you can't release these global memory areas. But the heap is often used for on-the-fly allocations of new memory blocks, by allocating memory for them.
But with Global variables, the code will know exactly where they are and thus write their exact location in the code. (Well, their location from the beginning of the data segment anyways.) Register variables are located in the CPU and the compiler knows exactly which register, which is also just told to the code. Stack variables are located at an offset from the current stack pointer. This stack pointer will increase and decrease all the time, depending on the number of levels of procedures calling other procedures.
Only heap values are complex. When the application needs to store data on the heap, it needs a second variable to store it's address, otherwise it could lose track. This second variable is called a pointer and is located as global data or as part of the stack. (Or, on rare occasions, in the CPU registers.)
Oh, it's even a bit more complex than this, but already I can see some eyes rolling due to this information overkill. :-)
Think of memory as a drawer into which you decide how to devide it according to your spontaneous needs.
When you declare a variable of type integer or any other type, the compiler or interpreter (whichever) allocates a memory address in its Data Segment (DS register in assembler) and reserves a certain amount of following addresses depending on your type's length in bit.
As per your question, an integer is 32 bits long, so, from one given address, let's say D003F8AC, the 32 bits following this address will be reserved for your declared integer.
On compile time, whereever you reference your variable, the generated assembler code will replace it with its DS address. So, when you get the value of your variable C, the processor queries the address D003F8AC and retrieves it.
Hope this helps, since you already have much answers. :-)