[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::decc

Title:DECC
Notice:General DEC C discussions
Moderator:TLE::D_SMITHNTE
Created:Fri Nov 13 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2212
Total number of notes:11045

2075.0. "V5.5 - /noop effects psect sizes" by CSC32::J_HENSON (Don't get even, get ahead!) Wed Jan 29 1997 15:32

Decc for OpenVMS Alpha V5.5-002, OpenVMS Alpha V7.0

I am seeing a difference in the size of a psect being generated depending
upon whether or not the code is compiled with /nooptimize.  The psect
is being defined as a union.  When compiled /noop, it has a smaller
(and correct) size.

The attached command illustrates this difference.

Please advise.

Jerry
-------------------------------------------------------------------
$cc/version nl:    !should be v5.5-002
$create union.c
union xscobuf {
        char    scope[2047][32];
        long    lscope[2047][8];
        short   p_scope[2047][16];
};
extern union xscobuf scobuf;
main(){}
$cc/extern=common union
$ana/obj/out=union1.ana union
$cc/extern=common/noop union
$ana/obj/out=union2.ana union
$diff/out=union.dif union1.ana union2.ana
$search/wind=5 union.dif scobuf
T.RTitleUserPersonal
Name		DateLines
2075.1WIBBIN::NOYCEPulling weeds, pickin' stonesWed Jan 29 1997 15:501
This is a duplicate of #2030 -- see replies .6 and .9
2075.2thanks, but...CSC32::J_HENSONDon't get even, get ahead!Thu Jan 30 1997 09:1928
>>      <<< Note 2075.1 by WIBBIN::NOYCE "Pulling weeds, pickin' stones" >>>

>>This is a duplicate of #2030 -- see replies .6 and .9

I don't wish to belabor the point, but I want to make sure that I'm
not missing something.

In 2030, the solution is to compile all c modules that use the
psect with /extern=common.  As I understand it, this will result in
all modules having the same incorrect length, but will still work.

In my case (and this is information I am just now providing), the
customer is linking a c module against a shareable image created
by a basic program, so I do not have the option of compiling everything
with /extern=common.  So far, the only workaround that I have found
is to compile the c code with /nooptimize.

Is this a reliable workaround?

Also, can you shed a bit more light on the nature of the problem?  Is it
simply a matter of using /extern=common creating a psect that is too large,
or are there other factors to consider.  I expect that the csc will see
more of this, and it would be nice to be able to fully explain the
situation to our customers (and for us to fully understand the situation).

Thanks,

Jerry
2075.3COMMONs regularly cause problems...XDELTA::HOFFMANSteve, OpenVMS EngineeringThu Jan 30 1997 09:477
   I'd *strongly* look at using a process or global section, and get rid
   of the COMMON.  (The COMMON can cause maintenance problems, and quite
   regularly requires relinking.  Sections do not.)  Alternatively, have
   the C code locate the virtual address of the COMMON at run-time, and
   use pointers.  (I can point you at some of my previous anti-COMMON
   rants, if you'd like.  :-)