This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem with .cdecls assembler directive for C6x 7.0.0.B4 compiler under EABI

Take the following program test.asm:

        .cdecls C, LIST
        %{
        struct foo;
        int foo(void);
        %}

Compile it with:

cl6x.exe -c --abi=eabi test.asm

The following error is printed:

"c:\temp\045084", ERROR!   at line 34: [E0300] Structure tag can't be global
        foo        .struct 0,1          ; struct size=(0 bytes|0 bits), alignment=0

"c:\temp\045084", ERROR!   at line 38: [E0004] Invalid identifier 'foo'
                                               specified
                   .global foo

Obviously, the assembler complains about a .struct, whose tag is 'foo',
and later a '.global foo' function is defined.

Probably the assembler should be fixed not to confuse structure tags
with global symbols definitions. Note that this issue does not exist
with COFF ABI, because there the function is '.global _foo'.

Precisely the same behavior is manifested by the TMS470 compiler.

  • In the assembler, structure names and global symbols are in the same namespace.  Thus, you cannot have a structure and a global symbol (such as the name of a function) with the same name.  In C, on the other hand, the structure namespace and global symbol namespace are distinct, and names can be repeated.  This has always been the case.

    You show that under EABI, a global symbol in C has the same representation in assembly.  "foo" in C is "foo" in assembly.  You also point out that under older COFF ABI, "foo" in C is "_foo" in assembly.  So, while a name collision between a struct and a global symbol has always been possible, it is more likely under EABI.  

    So, I view this as a deficiency in TI documentation for failing to point this out.  And the diagnostics could be more helpful.  Do you agree?  Or, do you have a compelling reason to have a structure and global symbol with the same name?

    Thanks and regards,

    -George

     

  • The explanation is understood. However, here are the following reasons to prefer this behavior fixed in the Assembler. First, having structures and functions with same name is prettly legal C, and one would expect that assembling would produce a warning and/or reduce the declarations to nops, but not to generate an error. Second, there are at least two such cases in *standard* (POSIX) headers - struct sigaction {} and sigaction() in signal.h, and struct stat{} and stat() in sys/stat.h.

    Anyway, an easy workaround is to redefine function symbols as static in the .cdecls block, e.g.

            #ifdef __TI_EABI__
                #define sigaction(x,y,z) static sigaction(x,y,z)
            #endif
           #include <signal.h>

    Sure this works only if the function is not called from assembly.

  • I filed this as an enhancement in our ClearQuest tracking database.  Its id SDSCM00035270.  You can track the enhancement report at this page.  (Enter the full id in the 'Find Record ID' box.) 

    The cdecls assembly is generated by the parser, after the assembly first processes the cdecls directive.  The problem is that the parser generates this assembly:

    foo .struct 0,1

        .endstruct

       .global foo

    At this moment, we'll have to spend some more time analyzing the problem to see if there is a way to implement a fix.