Re: [OBJDUMP debugging] inlined enum

[Nick Clifton <nickc at redhat dot com>]

Hi Giovanni,

> I think the problem is related with a bad
> interpretation of the #include dependency graph, that
> we can follow using the "include line directives" in
> the source file.  
>
> A.h
>     include B.h
>         define enum ENUM_E
>     include D.h
>         define STRUCT1_S (use ENUM_E)  
>     define STRUCT2_S (use ENUM_E)         <<<<
>
> In debugging we have:
>
> A.h
>     define STRUCT2_S (use ENUM_E)        <<<< !!??!!
>     include B.h
>         define enum ENUM_E
>     include D.h
>         define STRUCT1_S (use ENUM_E)
>
> STRUCT2_S (use ENUM_E) in A.h is swapped before the
> definition of ENUM_E. Why?

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.

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.

Cheers
  Nick