BEWARE LEFTOVER DECC$.. LOGICAL NAMES

OpenVMS x86 native compilers, cross compilers news and questions.

Topic author
mgdaniel
Valued Contributor
Posts: 72
Joined: Mon Feb 28, 2022 5:16 pm
Reputation: 0
Location: Adelaide, South Australia
Status: Offline
Contact:

BEWARE LEFTOVER DECC$.. LOGICAL NAMES

Post by mgdaniel » Wed Oct 30, 2024 8:36 pm

Quirky behaviour. Was building some C code when all of a sudden the build began to fail.

Code: Select all

X86VMS$ cc/version
VSI C x86-64 V7.5-009 (GEM 50XBR) on OpenVMS x86_64 V9.2-2
X86VMS$ cc GENERIC_CATEGORY_ERROR
unspecified generic_category error
X86VMS$ 
Reduced the reproducer to

Code: Select all

/*****************************************************************************/

#include <stdio.h>

main (int argc, char* argv[])

{
   for (int cnt = 0; cnt < argc; argc++)
      printf ("%s\n", argv[cnt]);
}

/*****************************************************************************/
Huh? Eventually realised (probably) activating Apache had left my process with

Code: Select all

(LNM$PROCESS_TABLE)

  "DECC$EFS_CASE_PRESERVE" = "ENABLED"
  "DECC$EFS_CASE_SPECIAL" = "ENABLED"
  "DECC$EFS_CHARSET" = "ENABLED"
  "DECC$FILE_SHARING" = "ENABLED"
Deassigning these logical names resulted a clean compile of both the reproducer and the original application.

Code: Select all

X86VMS$ cc GENERIC_CATEGORY_ERROR
X86VMS$
BEWARE LEFTOVER DECC$.. LOGICAL NAMES


hb
Master
Posts: 152
Joined: Mon May 01, 2023 12:11 pm
Reputation: 0
Status: Offline

Re: BEWARE LEFTOVER DECC$.. LOGICAL NAMES

Post by hb » Mon Nov 04, 2024 9:33 am

arne_v wrote:
Thu Oct 31, 2024 9:16 pm
$ LINK/CRTL=(XXX,YYY,NOZZZ,NOWWW) ...

?

(the linker would generate a LIB$INITIALIZE that did what was specified and link it in)

If enough people like it then we just need to convince the VSI LINK person to implement it.
Whoever the VSI person/employee is, what if this "LINK person" doesn't like to generate code? "generate a LIB$INITIALIZE" is very generic. Image initialization requires code and a LIB$INITIALIZE PSECT, provided by an object module. (It also requires the linker to include a LIB$INITIALIZE module from STARLET.OLB. The x86 linker does this if it sees a LIB$INITIALIZE PSECT in an (user) object module.) So "generate a LIB$INITIALIZE" translates to generate code and generate a PSECT containing the address of the generated code - and I just ignore that there should be unwind information for the generated code as well. It's probably doable, but from my point of view not worth the effort. There should be a simpler, easier solution.
jreagan wrote:
Fri Nov 01, 2024 9:28 am
Maybe a tool to help write that awkward LIB$INITIALIZE contribution?
The compiler, as in

Code: Select all

__attribute__((section(".init_array"))) void (*pfoo)(void) = &foo;
? OK, I know what works on x86 and what not.

But It should be possible to find all the features and with the help of Perl to write the required 20 lines per source module. Or to provide a template(s?) and use sed or any other stream editor to convert that to the wanted source code.
jonesd wrote:
Sun Nov 03, 2024 5:53 pm
$ link/vector=(C$FEATURE_INIT,symbol1,symbol2,...)
I don't understand what this means and how this is supposed to work. You may want to add some more explanations/details.

Some questions and comments come to mind. Symbol1, symbol2,... are names. What should the linker write to the C$FEATURE_INIT PSECT? Their values? What are these values, addresses of data? Where are these symbols defined? In object modules that the linker includes when producing the image? Why should the linker create this PSECT rather than the compiler on behalf of the developer from the source code? I don't see why the linker should do this. The only advantage I see is, that the linker can terminate the list and it doesn't need to pull in a module with PSECT wrappers.

If the symbol value is an address, then the data will probably be a list of feature strings like "DECC$ARGV_PARSE_STYLE=TRUE" (or equivalent data). Regardless of what the data is and how the PSECT with the address data is generated, how would DECC$MAIN find the data? At run time of the image, there are no symbols. If you need the symbol to get its value, then you need to lib$fis the image. But this is/was designed only for shareable images. At run-time there are no PSECTs. From what I understand, the main image needs to pass at least one address to the CRTL, that DECC$MAIN can pick up. And that needs to happen before DECC$MAIN is called. Then we are back at image initialization code. But, as I said, I do not (yet) understand all the details of what is suggested.


jreagan
VSI Expert
Master
Posts: 219
Joined: Tue Dec 01, 2020 8:40 am
Reputation: 0
Status: Offline

Re: BEWARE LEFTOVER DECC$.. LOGICAL NAMES

Post by jreagan » Tue Nov 05, 2024 3:39 pm

hb wrote:
Mon Nov 04, 2024 9:33 am
jreagan wrote:
Fri Nov 01, 2024 9:28 am
Maybe a tool to help write that awkward LIB$INITIALIZE contribution?
The compiler, as in

Code: Select all

__attribute__((section(".init_array"))) void (*pfoo)(void) = &foo;
? OK, I know what works on x86 and what not.
That is C++, not in C. And I don't recommend mixing .init_array and LIB$INITIALIZE. The two mechanisms don't deal with mixed dependencies. And if you try LIB$INITIALIZE as the section name, you'll get the wrong alignment (quad vs long) even if you have 32-bit pointers enabled.

User avatar

arne_v
Senior Member
Posts: 575
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: BEWARE LEFTOVER DECC$.. LOGICAL NAMES

Post by arne_v » Tue Nov 05, 2024 11:16 pm

C++ or clang.

Code: Select all

$ type psect.c
#include <stdio.h>

void f()
{
    printf("hi\n");
}

__attribute__((section(".init_array"))) void (*fptr)(void) = &f;

int main()
{
    if(sizeof(' ') == sizeof(int))
    {
        printf("(this is C)\n");
    }
    if(sizeof(' ') == sizeof(char))
    {
        printf("(this is C++)\n");
    }
    return 0;
}

$ cc psect

__attribute__((section(".init_array"))) void (*fptr)(void) = &f;
..............^
%CC-E-NOTEXPECTING, Error parsing parameter list. Found "(" when expecting one of: <type-specifier>, <identifier>, "...", ")".
at line number 8 in file DKA0:[arne]psect.c;1
$ clang psect.c
$ link psect
$ run psect
hi
(this is C)
$ type psect.cpp
#include <stdio.h>

void f()
{
    printf("hi\n");
}

__attribute__((section(".init_array"))) void (*fptr)(void) = &f;

int main()
{
    if(sizeof(' ') == sizeof(int))
    {
        printf("(this is C)\n");
    }
    if(sizeof(' ') == sizeof(char))
    {
        printf("(this is C++)\n");
    }
    return 0;
}

$ cxx psect
$ link psect
$ run psect
hi
(this is C++)
$ clang psect.cpp
$ link psect
$ run psect
hi
(this is C++)
$ exit
Arne
arne@vajhoej.dk
VMS user since 1986


hb
Master
Posts: 152
Joined: Mon May 01, 2023 12:11 pm
Reputation: 0
Status: Offline

Re: BEWARE LEFTOVER DECC$.. LOGICAL NAMES

Post by hb » Wed Nov 06, 2024 5:39 am

It is a GNU C extension that clang supports (which is not surprising, as it probably supports many or all gcc extensions). The code snippet is from my gcc example for image initialization. I should have mentioned it and emphasized "as in".

And by the way, in my example is foo a static function.

Post Reply