[OBJDUMP debugging] inlined enum

[Giovanni Visciano]

Hi Nick,

> I think that this is a "feature" of the way that the debugging  
> information is
> displayed.  Essentially the code displays *all* of the debug  
> information
> associated with one particular file before going on to display the  
> debug
> information associated with any other files, and it displays the  
> files in the
> order that they were encountered.
>
> Thus in your stubs2.c example it shows all of the STABS debug  
> information
> associated with stub2.c before it shows any information associated  
> with
> ../inc/A.h, and it shows all of the information associated with ../ 
> inc/A.h
> before the information associated with ../inc/B.h.
>
> The other part of the "feature" is that the debug information  
> display code
> refuses to refer to an *anonymous* type before its definition has been
> displayed.  Even if that anonymous type is typedef'ed to a named  
> type.  Here is
> an example using just structs to show that this problem/feature is  
> not restricted to just enums:
>
>  % cat fred.c
>  typedef struct { int a; } before_include;
>  #include "z.h"
>  typedef struct { anon_struct field1; named_struct field2; }  
> after_include;
>
>  % cat z.h
>  typedef struct { int a; } anon_struct;
>  typedef struct named_struct { int a; } named_struct;
>
>  % gcc -c -gstabs fred.c
>  % objdump --debugging fred.o
> [Note: boring stuff skipped]
>  fred.c
> [Note: boring stuff skipped]
>  typedef struct %anon1 { /* size 4 */
>    int a; /* bitsize 32, bitpos 0 */
>  } before_include;
> [Note: The contents of z.h are not displayed here.]
>  typedef struct %anon2 { /* size 8 */
>    struct %anon1 { /* size 4 */
>      int a; /* bitsize 32, bitpos 0 */
>    } field1; /* bitsize 32, bitpos 0 */
>    struct named_struct /* id 3 */ field2; /* bitsize 32, bitpos 32 */
>  } after_include;
> [Note: Now z.h is displayed after all of fred.c has been displayed.]
>  z.h:
>  typedef struct %anon1 anon_struct;
>  struct named_struct { /* size 4 id 3 */
>    int a; /* bitsize 32, bitpos 0 */
>  };
>  typedef struct named_struct /* id 3 */ named_struct;
>
>
> This suggests a simple workaround for the problem - always name your  
> structs, unions and enums, even when they are being typedef'ed.

Yes, this could be a good habit.

> Frankly I am not keen on diving into the stabs display code and  
> finding out where this bias against anonymous types is implemented,  
> especially since these days DWARF is the debugging format of  
> choice.  If you would like to investigate for yourself however  
> please do, and it you find something and want to submit a patch I  
> will be happy to review it.

I agree with you.
I known DWARF is a much better choice (more structured,  
formalized, ...), and I have proposed to adopt it in the project I am  
working on, but for the moment ... other priority!
Unfortunately, I have no free slot of time to go on stabs code.

Thank you Nick for your help.

	Giovanni


Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com