C on X86 : Static procedures can be set as globals

[joukj]

Hi all,

Consider the following:

Code: Select all

rumba-jj) cc/vers
VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1  
rumba-jj) ty test1.c
typedef int (*Algo)(int dstSize);

static int jj( int i )
{
   return i;
}

static int jjj( int i )
{
   return i;
}

int jj1( int i )
{
  static const Algo decompress[2] = { jj, jjj};
   
   return decompress[ i ](5);
}
   8-DEC-2023 13:39:06
rumba-jj) ty test2.c
typedef int (*Algo)(int dstSize);

static int jj( int i )
{
   return 7*i;
}

static int jjj( int i )
{
   return 5*i;
}

int jj2( int i )
{
  static const Algo decompress[2] = { jj, jjj};
   
   return decompress[ i ](5);
}
   8-DEC-2023 13:39:11
rumba-jj) cc test1.c
rumba-jj) cc test2.c
rumba-jj) lib/crea jj.olb test1.obj,test2.obj
%LIBRAR-E-DUPGLOBAL, global symbol jjj from file $DSTM:[JOUKJ.test.bugs.c.stat_g
lob]test2.OBJ;1 already in library $DSTM:[JOUKJ.test.bugs.c.stat_glob]jj.olb;1

jjj (and jj) is defined static but appears as a global symbol in the object file. (the list-file (if created) gives it as a static).
I did not see this problem with the previous C-compiler. Also on AXP & IA64 I do not see this.
It is definitely a feature (???) of the new C-compiler on X86 to place sometimes static symbols as global symbols in the object file.

regards
Jouk

[levitte]

I've hit the exact same problem when trying to build OpenSSL, 3 using that exact same compiler version:

Code: Select all

LIBRARY/CREATE/OBJECT OSSL$libcrypto.OLB
...
LIBRARY/REPLACE OSSL$libcrypto.OLB [.providers.implementations.ciphers]libdefault-lib-cipher_aes_ocb.OBJ
%LIBRAR-E-DUPGLOBAL, global symbol aes_ocb_cipher from file USER:[LEVITTE.WRK._OPENSSL-3_3_0-DEV-X86_64.providers.implementations.ciphers]libdefault-lib-cipher_aes_ocb.OBJ;2 already in library USER:[LEVITTE.WRK._OPENSSL-3_3_0-DEV-X86_64]OSSL$LIBCRYPTO.OLB
%MMS-F-ABORT, For target OSSL$LIBCRYPTO.OLB, CLI returned abort status: %X108680B2.
%MMS-F-ABORT, For target BUILD_SW, CLI returned abort status: %X10EE8034.

Judging from hints I'm picking up over on github (https://github.com/openssl/openssl/issues/22899), it appears that this may be a recent issue? @Antinode-org appears to have been able to build OpenSSL 3 with an earlier build of the compiler (X7.4-785 (GEM 50X65)).

Side note: The offending symbol in my case is defined the same way through out all OpenSSL 3 releases, so it makes no difference if the build is OpenSSL 3.0.12 or 3.3.0-dev (current master branch):

Code: Select all

$ git grep ' aes_ocb_cipher('
crypto/evp/e_aes.c:static int aes_ocb_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
providers/implementations/ciphers/cipher_aes_ocb.c:static int aes_ocb_cipher(void *vctx, unsigned char *out, size_t *outl,

Added in 26 minutes 16 seconds:
A small detail I noticed is that while jjj is indeed made a global symbol, jj isn't:

Code: Select all

$ ana/obj/gsd/sect=symtab test1.obj
...
00000410 000000A8  Symbol 7. (00000007)          "jj"
00000410 000000A8    Name Index in Sec. 1.:              00000077     119.
00000414 000000AC    Symbol Info Field:                        02                                       symtab$b_st_info
                       Symbol Type:                            02          STT_FUNC
                       Symbol Binding:                         00          STB_LOCAL
00000415 000000AD    Symbol 'Other' Field:                     00                                       symtab$b_st_other
                       Symbol Visibility                       00          STV_DEFAULT
00000416 000000AE    Bound to section:                       0004       4. "$CODE$"                     symtab$w_st_shndx
00000418 000000B0    Symbol Value                0000000000000000       0.                              symtab$pq_st_value
00000420 000000B8    Size associated with sym:   0000000000000009                                       symtab$q_st_size
...
000004D0 00000168  Symbol 15. (0000000F)          "jjj"
000004D0 00000168    Name Index in Sec. 1.:              00000076     118.
000004D4 0000016C    Symbol Info Field:                        12                                       symtab$b_st_info
                       Symbol Type:                            02          STT_FUNC
                       Symbol Binding:                         01          STB_GLOBAL
000004D5 0000016D    Symbol 'Other' Field:                     00                                       symtab$b_st_other
                       Symbol Visibility                       00          STV_DEFAULT
000004D6 0000016E    Bound to section:                       0004       4. "$CODE$"                     symtab$w_st_shndx
000004D8 00000170    Symbol Value                0000000000000010      16.                              symtab$pq_st_value
000004E0 00000178    Size associated with sym:   0000000000000009                                       symtab$q_st_size
....

[joukj]

It is indeed a annoying new feature of the new compiler. It impacts many open source packages. So far I found problems with:
-zstd
-libwebp
-ghostscript
-OpenSSL

[jreagan]

We have already fixed this in the compiler. The next kit will be out at the end of the month.

[jreagan]

FYI, a corrected C compiler is should be available any day now (and a new Pascal also) that corrects this bug. And it is re-versioned to now be V7.5. The X7.4 was a little confusing since V7.4 already exists on Alpha/Itanium.

[joukj]

chacked : i9t is solved in V7.5-009

[levitte]

Confirmed, OpenSSL 3.3.0-dev (current master branch) builds on x86_64 with C V7.5-9

Added in 1 minute 28 seconds:
I'm running the test suite at this point... That will be interesting