We have some legacy code with classes that have members that are used in Interlocked* functions calls.
I want to be sure that some member variables I have are aligned on 4 byte boundaries (for use with InterlockedIncrement, see http://blogs.msdn.com/b/oldnewthing/archive/2004/08/30/222631.aspx).
I can't find anything definitive that specifies the default alignment of structure members for VS 2010. Experimentally, I haven't been able to make a struct violate 4 byte alignment without changing the default packing. All I have been able to find out is that the default packing is 8 bytes and that we're using that everywhere.
http://blogs.msdn.com/b/oldnewthing/archive/2004/08/30/222631.aspx
What I want to know is do we need to add __declspec(align(4)) to every variable that is used in the Interlocked* calls?
Edit: I know about packing and how to do it. Apologies for not being specific enough. Will the CRT also allocate all of my structs so that, given the default packing of 8 bytes, all of my struct members will be, by default aligned on 4 byte boundaries?
Will 32 bit int static variables be aligned by default? I'm looking for some docs on VS, but I'm having a hard time finding docs to explain the defaults.
You can specify the packing for an entire structure by using the #pragma pack directive.
#pragma pack(4)
struct MyStruct
{
...
};
#pragma pack() // this reset the packing to default
You can change the structure member alignment directly in your project settings. The option is called "Struct member alignment". You have just to set it to 4 bytes.
http://msdn.microsoft.com/en-us/library/xh3e3fd0.aspx
Open the project's Property Pages dialog box. For details, see How to: Open Project > Property Pages.
Click the C/C++ folder.
Click the Code Generation property page.
Modify the Struct Member Alignment property.
You can use __declspec(align()) as per http://msdn.microsoft.com/en-us/library/83ythb65.aspx. You can use this with individual members of a struct. See the last example in the link above.
Related
I'm developing some software for microcontrollers, and I would like to be able to easily see which parts of the software are using how much memory. The software does not use dynamic memory allocation, I am only interested in static memory allocations (the bss and data sections).
All of this static memory is actually part of a single struct, which contains (most of the) memory the program works with. This is a hierarchy of structs, corresponding to the components of the program. E.g.:
struct WholeProgram {
int x;
struct ComponentA a;
struct ComponentB b;
};
struct ComponentA {
int y;
struct ComponentC c;
struct ComponentD d;
};
...
struct WholeProgram whole_program;
Ideally, I would like to see the memory usage represented with a multi-level pie chart.
I could not find anything that can descend into structures like this, only programs which print the size of global variables (nm). This isn't too useful for me because it would only tell me the size of the WholeProgram struct, without any details about its parts.
Note that the solution must not be in the form of a program that parses the code. This would be unacceptable for me because I use a lot of C++ template metaprogramming, and the program would surely not be able to handle that.
If such a tool is not available, I would be interested in ways to retrieve this memory usage information (from the binary or the compiler).
Rather than using nm, you could get the same information (and possibly more) by getting the linker to output a map file directly. However this may not solve your problem - the internal offsets of a structure can be resolved by the compiler and the symbols discarded and therefore need not be visible in the final link map - only the external references are preserved for the purposes of linking.
However, the information necessary to achieve your aim must be available to the debugger (since it is able to expand a structure), so some tool that can parse your compiler's specific debug information - perhaps even the debugger itself - but that is a long shot, I imagine that you would have to write such a tool yourself.
The answers to GDB debug info parser/description may help.
If you declare instances of the component structs at global scope instead of inside the whole_program struct, your map file should give you the sizes of each component struct.
Packing all the components into one single structure naturally results in only whole_program being listed in the map file.
Say I have a DLL contains a struct, but I don't know the details of this struct. But I have a void pointer which points to address of the struct.
Can anybody tell me how can I get the details of the struct? Such as output the struct to a text file.
Thank you!
You cannot know the details of the struct without the type definition. Copying a region starting with the void pointer without a type definition will give you the raw binary data, but you wont know where it ends, or which pieces represent which variables. Some of the values could be integer values or they could be pointer addresses. There are all sorts of possibilities.
You should try to obtain the header file.
You might be able to glean some information from the debug / symbol file if you have it (example .pdb files on Windows), or debugging the program with GDB on Linux, this will only work if you have a debug build of the program. Refer to the "whatis" and "ptype" commands in GDB.
You never know this without structure definition. Also there can be "holes" between the user's variables in the real memory placement because of the alignment and padding.
Say if you have,
struct mystr {
char x;
int y;
};
by default such structure most likely will have size 8, and after one byte of char x there will be three bytes of padding (in theory random values), and then 4 bytes of int y, but it depends on compiler and its directives.
class SomeClass
{
//some members
MemberClass one_of_the_mem_;
}
I have a function foo( SomeClass *object ) within a dll, it is being called from an exe.
Problem
address of one_of_the_mem_ changes during the time the dll call is dispatched.
Details:
before the call is made (from exe):
'&(this).one_of_the_mem_' - `0x00e913d0`
after - in the dll itself :
'&(this).one_of_the_mem_' - `0x00e913dc`
The address of object remains constant. It is only the member whose address shift by c every time.
I want some pointers regarding how can I troubleshoot this problem.
Code :
Code from Exe
stat = module->init ( this,
object_a,
&object_b,
object_c,
con_dir
);
Code in DLL
Status_C ModuleClass( SomeClass *object, int index, Config *conf, const char* name)
{
_ASSERT(0); //DEBUGGING HOOK
...
Update 1:
I compared the Offsets of members following Michael's instruction and they are the same in both cases.
Update 2:
I found a way to dump the class layout and noticed the difference in size, I have to figure out why is that happening though.
linked is the question that I found to dump class layout.
Update 3:
Final Update : Solved the problem, much thanks to Michael Burr.
it turned out that one of the build was using 32 bit time, _USE_32BIT_TIME_T was defined in it and the other one was using 64 bit time. So it generated the different layout for the object, attached is the difference file.
Your DLL was probably compiled with different set of compiler options (or maybe even a slightly different header file) and the class layout is different as a result.
For example, if one was built using debug flags and other wasn't or even if different compiler versions were used. For example, the libraries used by different compiler versions might have subtle differences and if your class incorporates a type defined by the library you could have different layouts.
As a concrete example, with Microsoft's compiler iterators and containers are sensitive to release/debug, _SECURE_SCL on/off , and _HAS_ITERATOR_DEBUGGING on/off setting (at least up though VS 2008 - VS 2010 may have changed some of this to a certain extent). See http://connect.microsoft.com/VisualStudio/feedback/details/352699/secure-scl-is-broken-in-release-builds for some details.
These kinds of issues make using C++ classes across DLL boundaries a bit more fragile than using straight C interfaces. They can occur in C structures as well, but it seems like C++ libraries have these differences more often (I think that's the nature of having richer functionality).
Another layout-changing issue that occurs every now and then is having a different structure packing option in effect in the different compiles. One thing that can 'hide' this is that pragmas are often used in headers to set structure packing to a certain value, and sometimes you may come across a header that does this without changing it back to the default (or more correctly the previous setting). If you have such a header, it's easy to have it included in the build for one module, but not another.
that sounds a bit wierd, you should show more code, it should 'move' if it being passed by ref, it sounds more like a copy of it is being made and that having the member function called.
Perhaps the DLL versions is compiled against a different version that you are referencing. check and make sure the header file is for the same version as the dll.
Recompile the library if you can.
The following is the situation. There is a system/software which is completely written in C. This C program spawns a new thread to start some kind of a data processing engine written in C++. Hence, the system which I have, runs 2 threads (the main thread and the data processing engine thread). Now, I have written some function in C which takes in a C struct and passes it to the data processing thread so that a C++ function can access the C struct. While doing so, I am observing that the values of certain fields (like unsigned int) in the C struct changes when being accessed in the C++ side and I am not sure why. At the same time, if I pass around a primitive data type like an int, the value does not change. It would be great if someone can explain me why it behaves like this. The following is the code that i wrote.
`
/* C++ Function */
void DataProcessor::HandleDataRecv(custom_struct* cs)
{
/*Accesses the fields in the structure cs - an unsigned int field. The value of
field here is different from the value when accessed through the C function below.
*/
}
/*C Function */
void forwardData(custom_struct* cs)
{
dataProcessor->HandleDataRecv(cs); //Here dataProcessor is a reference to the object
//of the C++ class.
}
`
Also, both these functions are in different source files(one with .c ext and other with .cc ext)
I'd check that both sides layout the struct in the same
print sizeof(custom_struct) in both languages
Create an instance of custom_struct in both languages and print the offset of
each member variable.
My wild guess would be Michael Andresson is right, structure aligment might be the issue.
Try to compile both c and c++ files with
-fpack-struct=4
(or some other number for 4). This way, the struct is aligned the same in every case.
If we could see the struct declaration, it would probably clearer. The struct does not contain any #ifdef with c++-specific code like a constructor, does it? Also, check for #pragma pack directives which manipulate data alignment.
Maybe on one side the struct has 'empty bytes' added to make the variables align on 32 bit boundaries for speed (so a CPU register can point to the variable directly).
And on the other side the struct may be packed to conserve space.
(CORRECTION) With minor exceptions, C++ is a superset of C (meaning C89), So i'm confused about what is going on. I can only assume it has something to do with how you are passing or typing your variables, and/or the systems they are running on. It should, technically speaking, unless I am very mistaken, have nothing to do with c/c++ interoperability.
Some more details would help.
I have a couple of functions in a namespace called stub.
I have to determine the exact start address of the namespace and the end address, of at least the size of the namespace in memory (to copy these functions into another process).
While this worked perfectly in Visual C++ 2008 by adding a
void stub_end() { }
at the end of the namespace and using
size_t size = reinterpret_cast<ULONG_PTR>(stub_end) - reinterpret_cast<ULONG_PTR>(stub_start);
to determine the size of the stub.
This worked because Visual C++ preserved the function order as it is in the .cpp file, however that does not seem to be the case in Visual C++ 2010 anymore.
How can I find out the size of the functions or the whole namespace/stub by using pragma directives, compiler/linker facilities or similar?
With the new push in security these days (heap randomization, layout randomization, etc..) I think this is going to be much more difficult. You may end up having to just copy each function individually.
You can try and place each function in a different section, using the VC++ equivalent GCC's attribute ((section ("name"))) http://www.delorie.com/gnu/docs/gcc/gcc_62.html and then use your technique, or you could place each function in a different source file.
The C++ language provides no guarantees for finding addresses or sizes of namespaces. That said, venture into assembly language and linker instructions.
Many assembly languages have an opcode or mnemonic for placing code at specific addresses. This allows a label to be set up to indicate the start of a memory area. Some linkers have variables for obtaining segment starting addresses and sizes. These would be user defined logical addresses.
In summary, use your assembly and linker tools to define public symbols for the namespace start and length or optionally the end of the segment. In your C++ program, access these labels as extern.