[OBJDUMP debugging] inlined enum

[Giovanni Visciano]

>
> > The reported code it's an intentionally simple
example.
> > This happens on a more nested an complex data
structure.
>
> Ok - this looks like a problem with the STABS
decoding code.  Is it possible  
> for you to produce a simple test case that
reproduces the problem ?   Something  
> that starts with a single source file would be good,
in case this turns out to  
> be a problem with how the stabs information is
produced in the first place.
>

I have isolated the problem cleaning and compiling
preprocessed C source file  (attached .c and
"debugging output").
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?
This cause the "inline enum" problem.

Thanks,
    Giovanni


      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stub2.c
Type: application/octet-stream
Size: 3520 bytes
Desc: 915850912-stub2.c
URL: <https://sourceware.org/pipermail/binutils/attachments/20080111/1da19b35/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stub2.deb
Type: application/octet-stream
Size: 1056 bytes
Desc: 3833356901-stub2.deb
URL: <https://sourceware.org/pipermail/binutils/attachments/20080111/1da19b35/attachment-0001.obj>