This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
objdump --debugging: problems with interpretation of dump
- From: Roul Oldenburger <oldenburger dot roul at rheinmetall-de dot com>
- To: Ian Lance Taylor <ian at wasabisystems dot com>,binutils at sources dot redhat dot com
- Date: Thu, 16 Oct 2003 16:20:51 +0200
- Subject: objdump --debugging: problems with interpretation of dump
- References: <3F7C03B0.50301@rheinmetall-de.com> <m3r81vg4ub.fsf@gossamer.airs.com>
Hello there, hi Ian,
I am asking the list and you directly because I think you did the work.
I have problems to make the right interpretation of objdump's output in
certain cases.
What I want to do is parse/extract structure descriptions from the
debugging information.
The executable is creating a shared memory area and puts instances of
structure types into it. The structure might be quit deep in a sense of
nested substructures. I want to reconstruct the tree, but also need to
calculate offset each component has to the startaddress. So I need to
calculate always from the top structure level.
The problem is in certain cases there is no usual description of the top
structure.
As an example this is a description of a top structure used for a shared
memory I can use to build the tree and calculate the offsets:
----
struct gen_siso_shared_memory_vme_env__vme_env_sm_description { /* size
208 id 1746 */
struct gen_siso_shared_memory_vme_env__vme_env_sm_basic_description
/* id 1688 */ _parent; /* bitsize 256, bitpos 0 */
struct gen_siso_shared_memory_vme_env__version_description /* id 1691
*/ version; /* bitsize 128, bitpos 256 */
struct gen_siso_shared_memory_vme_env__static_vme_env_sm_description
/* id 1734 */ static; /* bitsize 544, bitpos 384 */
struct gen_siso_shared_memory_vme_env__dynamic_vme_env_sm_description
/* id 1737 */ dynamic; /* bitsize 736, bitpos 928 */
};
----
This is the description of another top structure ... but it's empty and
says it is /* id 0 */
----
struct awu_siso_shared_memory__shared_memory_description { /* id 0 */
};
----
What also can be found is the following which almost look like it should
----
struct awu_siso_shared_memory__shared_memory_description___XVE { /* size
4 id 2712 */
struct awu_siso_shared_memory__shared_memory_basic_description /* id
2189 */ _parent; /* bitsize 256, bitpos 0 */
struct awu_siso_shared_memory__version_description /* id 2192 */
version; /* bitsize 128, bitpos 0 */
struct awu_siso_shared_memory__static_shared_memory_description /* id
0 */ *static___XVL; /* bitsize 32, bitpos 0 */
struct awu_siso_shared_memory__dynamic_shared_memory_table /* id 2706
*/ dynamic___XVA4; /* bitsize 207264, bitpos 0 */
struct awu_siso_shared_memory__future_description /* id 2709 */
future; /* bitsize 43904, bitpos 0 */
struct awu_siso_shared_memory__data_field_description /* id 2620 */
data_field; /* bitsize 8647040, bitpos 0 */
struct awu_siso_shared_memory__environment_description /* id 2694 */
environment; /* bitsize 28061216, bitpos 0 */
};
----
Unfortunately I don't know what the meaning of
-an id 0 description is
-the ___XVE name extension is
-the extensions (___XVL, ___XVA4) in the components names are or why
they are presented as pointer type
Also all bitpos are 0 ...
I am probably missing something but currently I don't know why this is
though the type declaration in the source looks different and the debug
info should look similar to the first example.
Where can I look? Is there a document explaining these cases?
Thanks for your help
Roul