Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VMS C broken in new interesting ways

126 views
Skip to first unread message

Richard Levitte

unread,
Aug 21, 2016, 2:12:45 PM8/21/16
to
I had a surprise breakage over very recent OpenSSL changes... it was a symbol that went invisible under certain circumstances. Very easy to reproduce:

foo.c: --------------------
#include <stdlib.h>

extern int *foo;

main()
{
foo = malloc(sizeof *foo);
}
---------------------------

common1.c: ----------------
#include <stdlib.h>

int *foo;
---------------------------

common2.c: ----------------
#include <stdlib.h>

int *foo = NULL;
---------------------------

Building: -----------------
CC /NOLIST/OBJECT=FOO.OBJ FOO.C
CC /NOLIST/OBJECT=COMMON1.OBJ COMMON1.C
libr/crea common1.olb common1.obj
link /exe=foo1.exe foo.obj,common1.olb/lib
%ILINK-W-NUDFSYMS, 1 undefined symbol:
%ILINK-I-UDFSYM, FOO
%ILINK-W-USEUNDEF, undefined symbol FOO referenced
section: $CODE$
offset: %X0000000000000120 slot: 1
module: FOO
file: USER:[LEVITTE.TEST.MISSING-SYM]FOO.OBJ;1
CC /NOLIST/OBJECT=COMMON2.OBJ COMMON2.C
libr/crea common2.olb common2.obj
link /exe=foo2.exe foo.obj,common2.olb/lib
---------------------------

So it seems that VMS C doesn't make a global variable entirely visible unless it's initialised, under certain circumstances.

$ cc/vers
HP C V7.3-018 on OpenVMS IA64 V8.4

Cheers,
Richard

Stephen Hoffman

unread,
Aug 21, 2016, 2:34:05 PM8/21/16
to
On 2016-08-21 18:12:44 +0000, Richard Levitte said:

> I had a surprise breakage over very recent OpenSSL changes... it was a
> symbol that went invisible under certain circumstances. Very easy to
> reproduce:
> ...
> So it seems that VMS C doesn't make a global variable entirely visible
> unless it's initialised, under certain circumstances.

Sure looks like the define versus declare case...
http://stackoverflow.com/questions/1433204/how-do-i-use-extern-to-share-variables-between-source-files-in-c/1433387#1433387

http://www.geeksforgeeks.org/understanding-extern-keyword-in-c/

--
Pure Personal Opinion | HoffmanLabs LLC

hb

unread,
Aug 21, 2016, 4:16:55 PM8/21/16
to
On 08/21/2016 08:12 PM, Richard Levitte wrote:
> #include <stdlib.h>
>
> int *foo;

OK, I tested this on Alpha, but it should be the same on I64, what you
are using.

On Alpha (V8.3, HP C V7.3-010)
$ sh symb cc
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
$
$ cc foo
$ cc common1
$ link foo, common1
$
$ libr/cre x common1
$ link foo, x/lib
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, FOO
%LINK-W-USEUNDEF, undefined symbol FOO referenced
in psect $LINK$ offset %X00000020
in module FOO file EISNER$DRA3:[DECUSERVE_USER.BECKER_H]FOO.OBJ;2
$ link foo, x/lib/incl=common1
$

It is librarian, which doesn't have the symbol foo in its global symbol
table.

Further, if you look at the object file, you will see, it is a weak
definition:

$ pipe anal/obj common1 |search sys$pipe "Global Symbol
Specification"/wind=(0,12)
3) Global Symbol Specification (EGSD$C_SYM)
data type: DSC$K_DTYPE_Z (0)
symbol flags:
(0) EGSY$V_WEAK 1
(1) EGSY$V_DEF 1
(2) EGSY$V_UNI 0
(3) EGSY$V_REL 1
(4) EGSY$V_COMM 1
(5) EGSY$V_VECEP 0
(6) EGSY$V_NORM 0
psect: 1
value: 0 (%X'00000000')
symbol: "FOO"
$

It seems (and I think it is documented somewhere) that librarian doesn't
include weak definitions in its GST. So the linker can't find it.
Explicitly including the module obviously helps.

$ libr/list/name x
Directory of ALPHA OBJECT library
EISNER$DRA3:[DECUSERVE_USER.BECKER_H]X.OLB;2 on 21-AUG-2016 16:07:01
Creation date: 21-AUG-2016 16:01:34 Creator: Librarian A09-30
Revision date: 21-AUG-2016 16:01:34 Library format: 3.0
Number of modules: 1 Max. key length: 128
Other entries: 0 Preallocated index blocks: 213
Recoverable deleted blocks: 0 Total index blocks used: 1
Max. Number history records: 20 Library history records: 0

Module COMMON1
$

int *foo = NULL;

creates a "normal" or strong definition and that symbol is in the GST of
the library.

There should be some documentation on weak symbols generated by the
compilers and how they are handled by the linker/librarian.

Richard Levitte

unread,
Aug 21, 2016, 4:54:11 PM8/21/16
to
Ah, I was wondering for a bit if it has to do with the extern model... turns out it does. If I add /EXTERN=STRICT, I got the behavior I expected...

So, not so broken after all... just a bit surprising in a VMS sort of way.

Cheers,
Richard
0 new messages