objdump: circular debug information error message // <undefined> types in output

[Roul Oldenburger]

Hi,

seems like nobody could help on my last question (see below) so I add 
this message to it:

I found 'objdump --debugging' printing lots of error messages/ warnings like

'debug_get_real_type: circular debug information for int'

and creating debug info output describing structures which have 
components in it with no type ...

'  <undefined> *static___XVL; /* bitsize 32, bitpos 0 */'

for example.

What I also found is that using the same version of binutils on the same 
executable but on a different machine ... there are no warnings about 
circular debug info given and the <undefined> entries are changed into 
the type I do expect.

Question: What did I wrong? What can I do to find out?

I took binutils 2.14 from its homepage and compiled it on either 
machine. I made sure I would use this newly compiled objdump.

I am sorry if it's something stupid and simple and I waste your time ... 
I have no idea - please tell me.

Roul



--------------------------------------------------------------------
> Hello again,
> 
> Ian already helped me with this topic but this time I guess its a problem of configuring binutils the right way and not an objdump question.
> 
> What happened... I am parsing 'objdump --debugging' output from executables compiled with GNAT from Ada sources to reconstruct trees of structure types. It worked fine with the given debuginfos until I came across empty type descriptions which have an 'id 0' entry. I found the expected type description with a special suffix added to its name '___XVE' with components in it having suffixes like '___XVA4' and '___XVL' ...
> as Ian guessed they are Ada specific and Joel from gdb said these things are explained in GNAT in exp_dbug.ads (found in gcc/ada).
> It says the given types having the XVE suffix are variable entities having one or more components with a variable length, which explains why bitpositions are all 0.
> So I expanded the parser and now came to the point where I found components with 'undefined' type designators ... which aren't very helpful.
> 
> An example:
> struct awu_siso_shared_memory__shared_memory_description___XVE { /* size 4 id 3576 */
>   struct awu_siso_shared_memory__shared_memory_basic_description /* id 3065 */ _parent; /* bitsize 256, bitpos 0 */
>   struct awu_siso_shared_memory__version_description /* id 3068 */ version; /* bitsize 128, bitpos 0 */
>   <undefined> *static___XVL; /* bitsize 32, bitpos 0 */
>   struct awu_siso_shared_memory__dynamic_shared_memory_table /* id 3570 */ dynamic___XVA4; /* bitsize 207264, bitpos 0 */
>   struct awu_siso_shared_memory__future_description /* id 3573 */ future; /* bitsize 43904, bitpos 0 */
>   struct awu_siso_shared_memory__data_field_description /* id 3496 */ data_field; /* bitsize 8647040, bitpos 0 */
>   struct awu_siso_shared_memory__environment_description /* id 3558 */ environment; /* bitsize 28061216, bitpos 0 */
> };
> 
> The component with variable length is missing the type ...
> 
> What I found is that running objdump on a different machine using the same executable gives a reasonable description without <undefined> types.
> 
> I have installed binutils 2.13.1 on my machine ... on the development system I cannot install a recent version of binutils (2.11 is there), so I unpacked and built (but not installed) binutils 2.14 in my development path.
> 
> Am I right if I guess the local objdump still uses the libbfd from the installed 2.11 ?
> How can I configure / install binutils separate without disturbing the current system?
> 
> Or am I totally wrong .... any other ideas?
> 
> Thanks a lot
> Roul