C on X86 : Static procedures can be set as globals


Topic author
joukj
Master
Posts: 150
Joined: Thu Aug 27, 2020 5:50 am
Reputation: 0
Status: Offline

C on X86 : Static procedures can be set as globals

Post by joukj » Fri Dec 08, 2023 7:49 am

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
Last edited by joukj on Fri Dec 08, 2023 7:58 am, edited 2 times in total.


craigberry
Member
Posts: 9
Joined: Fri Nov 17, 2023 11:27 am
Reputation: 0
Status: Offline

Re: C on X86 : Static procedures can be set as globals

Post by craigberry » Fri Dec 08, 2023 8:19 am

What happens when you compile /NOOPT. Does that make any difference?


Topic author
joukj
Master
Posts: 150
Joined: Thu Aug 27, 2020 5:50 am
Reputation: 0
Status: Offline

Re: C on X86 : Static procedures can be set as globals

Post by joukj » Fri Dec 08, 2023 8:30 am

Exactly the same with /NOOP

User avatar

tlovern
Active Contributor
Posts: 38
Joined: Tue Jul 21, 2020 10:44 am
Reputation: 0
Status: Offline

Re: C on X86 : Static procedures can be set as globals

Post by tlovern » Fri Dec 08, 2023 12:09 pm

had to edit my response after looking at the example again.

The issue appears to be the librarian and module names.

Global names in the librarian are the entry points.

You cannot have two identically named modules in a library. There is no way to tell them apart.

For example a JJ.obj from a C compile and a JJ.obj from a fortran compile have the same global key value, "JJ" They will not coexist in the same library without renaming one of the routine names.
Last edited by tlovern on Fri Dec 08, 2023 12:12 pm, edited 1 time in total.


jonesd
Valued Contributor
Posts: 68
Joined: Mon Aug 09, 2021 7:59 pm
Reputation: 0
Status: Offline

Re: C on X86 : Static procedures can be set as globals

Post by jonesd » Fri Dec 08, 2023 1:15 pm

tlovern wrote:
Fri Dec 08, 2023 12:09 pm
had to edit my response after looking at the example again.

The issue appears to be the librarian and module names.

Global names in the librarian are the entry points.

You cannot have two identically named modules in a library. There is no way to tell them apart.

For example a JJ.obj from a C compile and a JJ.obj from a fortran compile have the same global key value, "JJ" They will not coexist in the same library without renaming one of the routine names.
You can't have identically named module names, but the module name doesn't have to match the file name. Add
the following line to the top of jj.c
#pragma module jjc


hb
Valued Contributor
Posts: 57
Joined: Mon May 01, 2023 12:11 pm
Reputation: 0
Status: Offline

Re: C on X86 : Static procedures can be set as globals

Post by hb » Fri Dec 08, 2023 7:13 pm

The OP has it right. Unfortunately it is a (known) bug. Under some conditions this compiler converts a "static function" to a "global function". That is, the symbol of the static function incorrectly becomes a global symbol instead of being a local symbol. Global symbols will make it into the global symbol table of an object library. Local symbols will not. I expect this bug will be fixed soon.

In his example there are no identical object module names.
The issue appears to be the librarian and module names.
No.
Global names in the librarian are the entry points.
Global symbol names in an object library are used to identify an object module. That's what the linker needs: resolving an undefined symbol "from a library". Actually it includes the identified object module into the image.
You cannot have two identically named modules in a library.
True. But trying so will NOT result in an error: librarian will replace the existing object module with the new one, because you said so - no matter in which object file the identically named object module was found.

You cannot have two identical symbols in the global symbol table of a library. Trying so will result in an error, the reported DUPGLOBAL.
Last edited by hb on Fri Dec 08, 2023 7:20 pm, edited 3 times in total.


craigberry
Member
Posts: 9
Joined: Fri Nov 17, 2023 11:27 am
Reputation: 0
Status: Offline

Re: C on X86 : Static procedures can be set as globals

Post by craigberry » Sat Dec 09, 2023 9:08 am

Does changing the functions from "static" to "static inline" get you past the compiler bug?

User avatar

tlovern
Active Contributor
Posts: 38
Joined: Tue Jul 21, 2020 10:44 am
Reputation: 0
Status: Offline

Re: C on X86 : Static procedures can be set as globals

Post by tlovern » Sat Dec 09, 2023 11:28 am

jonesd wrote:
Fri Dec 08, 2023 1:15 pm
tlovern wrote:
Fri Dec 08, 2023 12:09 pm
had to edit my response after looking at the example again.

The issue appears to be the librarian and module names.

Global names in the librarian are the entry points.

You cannot have two identically named modules in a library. There is no way to tell them apart.

For example a JJ.obj from a C compile and a JJ.obj from a fortran compile have the same global key value, "JJ" They will not coexist in the same library without renaming one of the routine names.
You can't have identically named module names, but the module name doesn't have to match the file name. Add
the following line to the top of jj.c
#pragma module jjc
Correct, and I didn't see the use of Pragma in the code examples provided. (I may have missed them)


Topic author
joukj
Master
Posts: 150
Joined: Thu Aug 27, 2020 5:50 am
Reputation: 0
Status: Offline

Re: C on X86 : Static procedures can be set as globals

Post by joukj » Mon Dec 11, 2023 1:50 am

Static inline does not help

Added in 1 minute 34 seconds:
It is clear that the module names are not the problem. If you analyze the object file the procedures are listed as global.

User avatar

tlovern
Active Contributor
Posts: 38
Joined: Tue Jul 21, 2020 10:44 am
Reputation: 0
Status: Offline

Re: C on X86 : Static procedures can be set as globals

Post by tlovern » Mon Dec 11, 2023 11:28 am

hb wrote:
Fri Dec 08, 2023 7:13 pm
The OP has it right. Unfortunately it is a (known) bug. Under some conditions this compiler converts a "static function" to a "global function". That is, the symbol of the static function incorrectly becomes a global symbol instead of being a local symbol. Global symbols will make it into the global symbol table of an object library. Local symbols will not. I expect this bug will be fixed soon.

In his example there are no identical object module names.
The issue appears to be the librarian and module names.
No.
Global names in the librarian are the entry points.
Global symbol names in an object library are used to identify an object module. That's what the linker needs: resolving an undefined symbol "from a library". Actually it includes the identified object module into the image.
You cannot have two identically named modules in a library.
True. But trying so will NOT result in an error: librarian will replace the existing object module with the new one, because you said so - no matter in which object file the identically named object module was found.

You cannot have two identical symbols in the global symbol table of a library. Trying so will result in an error, the reported DUPGLOBAL.
Not the first time I've been wrong in my understanding of what Librarian is doing, just anecdotal observations, which I misinterpreted. So, I learned something.

Post Reply