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.