Thomas De Schampheleire writes: > I need to read fields in kernel structures directly from memory (from > within a simulator).
Can you explain the simulator in more detail? > Using mdb I can extract the necessary offset > values for the different fields in different structures (like proc, > kthread_t, ...). In general, unless you find documentation on the data structure in a man page (along with a stability level), the data structure is private to the implementation. That means that it may change at any time at all, and without notice. > My question is: how fixed are these offsets? Will they always be the > same within a same kernel version? Does it depend on the structure > instance as well? I noticed there are unions inside the structure I am > interested in, does this make a difference? (How is union memory > allocated?) Unless you have a specific set of variables, it's impossible to answer that question. Interface stability has finer granularity than that. The short answer, though, is that if you're groveling about in /dev/kmem, then you're looking at implementation details that may vary without notice. No reliable software should depend on those bits. > Is there a way to verify that the numbers mdb will give are correct? > Can I for example calculate the actual offset of a field by counting > the sizeof()s of the preceding fields from the source? I don't understand. Mdb will give you the right answers ... what are you "verifying?" > About alignment: is it possible that the order of fields is changed so > the gaps aren't too big? > Suppose for example there is an int - char - int - char and that an > int is 4 bytes and char is 1 byte. With a 32-bit memory, one could > keep the order and align on 4-byte boundaries. This would mean that in > total 16 bytes will be used. If however, order is changed, both char's > can be put together, and then only 12 bytes will be used. Most sane compilers do not pack structures by default, for performance reasons. That would be a 16 bytes. > Is it correct that for a union, the allocated memory is as big as the > largest member of the union? Yes. Actually, you need to know about the trailing padding as well -- structures are sized based on the strictest alignment requirement of any member. So "int - char" is actually 8 bytes, with 3 bytes of pad after that char member. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-code mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
