- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Global Section Problem of IA64
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2009 12:07 AM
тАО12-10-2009 12:07 AM
SolutionNow to the real problem in the way the global section is mapped:
I assume the section is mapped by a $CRMPSC or $MGBLSC call:
the psect on IA64 is less than 2 pages, but the global section is mapped to the next page boundary (16384 bytes), i.e. whatever is following in the programs address space after the PLGRP_TABLE array is also mapped to the global section and zeroed (SEC$M_DZRO is default if it is a page file section).
So to resolve the issue, make the length of the array an integral multiple of the page size (or put it into a structure which is padded to the page boundary by a dummy array),
and at best verify at runtime the actual page size is the same as the one assumed at compile time: then the program is save against future VMS and/or CPU developments.
Maybe it helps to read the comments in
http://www.mppmu.mpg.de/~huber/util/crmpsc.FOR
(although written in Fortran): it was working initially for vax, then adapted for Alpha, and is valid for IA64 as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2009 12:47 AM
тАО12-10-2009 12:47 AM
Re: Global Section Problem of IA64
It is just like you described.
Now what I want to know is:
is it natrual or abnormal caused by some reason.
If it is natrual, maybe padding a 8192 space will be a easy & good idea to deal with it.
But if is is an issue should be fixed, then investigate the root reason will be necessary.
And altogether, thanks very much for your help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2009 01:12 AM
тАО12-10-2009 01:12 AM
Re: Global Section Problem of IA64
natural what?
The psect length is not aligned to the (target-) systems page size by all compilers I use. Fortran e.g. has options to align natural, and then the length is padded to the next 16 (or is it 32 ?) byte boundary to produce the same psect size as an equivalent C program.
So psects destined to be mapped to global sections should be a multiple of the page size, using structure paddding or "guard pages" or whatever means to adjust the ending address mapped.
Your program had the problem from the beginning, it just was covered by the 64K size of the psect: where this 64K come from You have to find out yourself looking at the map or the program sources.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2009 08:11 AM
тАО12-10-2009 08:11 AM
Re: Global Section Problem of IA64
I do not at all like how this appears to work, but I guess 'it worked'.... sort of.
If this was my issue, and I needed to get go on this in a hurry, then I would GENERATE a dedicated C module with over allocated PSECTS for each of the PSECT which are supposed to me mapped.
I would use PERL or DCL on the Alpha MAP to generate just CHAR variables big enough to match each Alpha Psect.
That should allow you to move forward.
With that in place I'd want to understand what is really behind this.
You might also want to use the linker COLLECT option to collect PSECTs which are NOT re-mapped all together.
And most certainly I'd talk with development to step away froom allocating and re-mapping towards just CRMPSC and use the addresses as returned.
Cheers,
Hein
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2009 05:14 PM
тАО12-10-2009 05:14 PM
Re: Global Section Problem of IA64
Since I do not have enough time to investigate it clearly, I decided to find a work around to deal with it.
And I tried yesterday, and it worked.
Here is the points:
1. Give a 8192(8k) dummy space after every GS variables declared by "_align(PAGE)".
2. The dummy space also should be declared as "_align(PAGE)".
3. The variable name of dummy date should be as alphebit order as the former GS varibale, so that it should be adjoined togeter when linking.
( A typedef struct method seemed to take no effects)
Although the work around seemed dirty, but it really worked.
Now thanks you everyone again for your help.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2009 08:07 PM
тАО12-10-2009 08:07 PM
Re: Global Section Problem of IA64
Looking as the MAP some more, I noticed you used an OLD C compiler and oldish linker.
Rule #1 in Alpha -> Itanium porting: Compile with the most recent Alpha compiler first, to clear out any latent problems!
Anyway I tried the workaround I hinted at.
It works fine, of course.
Consider this PERL (long) one-liner:
perl -ne "print qq(char _align(PAGE) ${1}[$2];\n) if /^(\S+)\s.*0000 \(\s+(\d+).. PAGE.*OVR/ && !$x{$1}++" alpha.map > helper.c
That looks for lines for the first time defining a PSECT which is 10000x aligned and overlayed. For those it prints a C line like:
helper.c
char _align(PAGE) PLAN_TABLE[23068672];
char _align(PAGE) PLGRP_TABLE[65536];
char _align(PAGE) SPAT_MNG_VAL_TABLE[131072];
Create test main like:
tmp.c
int _align(PAGE) plgrp_table[10000];
int _align(QUADWORD) pwash_que_bot;
main (){
}
Compile and link with map, and search the map.
$ CC TMP
$ CC HELPER
$ LINK/MAP TMP,HELPER
$ sea/win=(0,5) tmp.map PLGRP_TABLE
PLGRP_TABLE 0DE20000 0DE2FFFF 00010000 ( 65536.) PAGE 16
TMP 0DE20000 0DE29C3F 00009C40 ( 40000.) PAGE 16
HELPER 0DE20000 0DE2FFFF 00010000 ( 65536.) PAGE 16
PWASH_QUE_BOT 0DE30000 0DE30003 00000004 ( 4.) OCTA 4
TMP 0DE30000 0DE30003 00000004 ( 4.) OCTA 4
SPAT_MNG_VAL_TABLE 0DE40000 0DE5FFFF 00020000 ( 131072.) PAGE 16
So now the total Psect size is defined by the helper to match the size as found in the Alpha link map.
Btw.... C V7.1-015-48F8P did something funny:
PERICLE_EQP_TABLE 22 65536 page
PLAN_TABLE 23 23068672byte
PLGRP_TABLE 24 65536 page
SPAT_MNG_VAL_TABLE 25 131072 page
See that 'byte' in the middle? I did not ask for that!
Hein
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2009 11:32 PM
тАО12-10-2009 11:32 PM
Re: Global Section Problem of IA64
why use this 'workaround', and not finally make the program correct by just changing the array length PL_GRP_MAX to a page-length multiple ?
Apparently You have access to the source to insert the 'dumy' space variables, so why not change the definition of PL_GRP_MAX ?
As Hein demonstrates, relying on the alphabetic order of global variables is very dangerous.
If changing PL_GRP_MAX is not possible , then a secure alternative is the CLUSTER option in LINK: make a cluster of the PLGRP_TABLE psect and some dummy psect with a name being later in alphabetic order. Other than the behaviour of different compilers, the linker guarantees the alphabetic order of psects in a cluster, and You don't have to touch the source, except adding a separate mudule defining the dummy psect.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-11-2009 12:24 AM
тАО12-11-2009 12:24 AM
Re: Global Section Problem of IA64
Source of the dummy psect _dummy.c:
#include
//vms_pagesize contains the architecture-dependant pagesize like
// #define VMS_PAGESIZE 8192
unsigned char _DUMMY[VMS_PAGESIZE];
$ CC/EXTERN_MODEL=COMMON _dummy
Then link it:
$ LINK myobject,...,_dummy,sys$input/opt
COLLECT=mycluster,PRGRP_TABLE,_DUMMY
This way it is always guaranteed PRGRP_TABLE is followed by the dummy psect as a rear guard page.
Note the underscrore in the _DUMMY psect name, which forces it behind all others (although it may violate C purists name-space rules :-).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-11-2009 01:40 AM
тАО12-11-2009 01:40 AM
Re: Global Section Problem of IA64
It is an error to mix extern models. The linker uses the OVR PSECT PLGRP_TABLE to define the relaxed refdef symbol PLGRP_TABLE.
A linker /MAP/FULL shows the contributors. In the relaxed refdef model you see only the
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-11-2009 05:17 AM
тАО12-11-2009 05:17 AM
Re: Global Section Problem of IA64
Well alphabetic is not a big big problem.
Just append a "$" to the name? and yes I also suggested the collect to get some control.
Hartmut,
I'm not sure I understand what you are trying to say, and I know one should not dismiss your remarks.
I believe to see the PLGRP_TABLE having contributions from both TMP and HELPER where helper is the bigger on and defines the final, rounded up, size.
Neither provide init value.
I had checked and tried various options working with the ever important Tables 4├в 4:External Models and Definitions, and Table 4├в 7: Combination Attributes in the C-USER GUIDE.
In the end I compiled and linked with no options which I beliewe gave me flavor (1) = #pragma extern_model common_block noshr.
I don't think that creates a mix, but please help me understand if it does. Is there a confusion between definer and referencers?
I did this on ALPHA first, where the linker nicely shows each contribution.
Based on you entry I also checked IA64, and sure enough is show NO module as contributor, only
But the sizes were right (as desired) and it makes sense in so far as no single byte came from the modules themselves, it is just the linker doing smoke and mirrors.
So I think the program would work as expected, even though that expectation was crooked/ugly.
Here are the complete sections from the MAP file generated. I added in one more variable (top) to proof it would be tightly against the (bot) and not skip to the next 10000x boundary.
I'd still like to figure out how the original Alpha code ended up rounding up those _align(PAGE) entries.
Maybe is was specific to the compiler version used by Kai? ( Compaq C V6.4-008 ).
_all_ the modules had this, so it was not an explicit 'helper' as in my workaround.
Hein.
PLGRP_TABLE 0DE20000 0DE2FFFF 00010000 ( 65536.) PAGE 16 NOPIC,OVR,REL,GBL,NOSHR,NOEXE, WRT,NOVEC,NOMOD
TMP 0DE20000 0DE29C3F 00009C40 ( 40000.) PAGE 16
HELPER 0DE20000 0DE2FFFF 00010000 ( 65536.) PAGE 16
PWASH_QUE_BOT 0DE30000 0DE30003 00000004 ( 4.) OCTA 4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE, WRT,NOVEC,NOMOD
TMP 0DE30000 0DE30003 00000004 ( 4.) OCTA 4
PWASH_QUE_TOP 0DE30010 0DE30013 00000004 ( 4.) OCTA 4 NOPIC,OVR,REL,GBL,NOSHR,NOEXE, WRT,NOVEC,NOMOD
TMP 0DE30010 0DE30013 00000004 ( 4.) OCTA 4
SPAT_MNG_VAL_TABLE 0DE40000 0DE5FFFF 00020000 ( 131072.) PAGE 16 NOPIC,OVR,REL,GBL,NOSHR,NOEXE, WRT,NOVEC,NOMOD
HELPER 0DE40000 0DE5FFFF 00020000 ( 131072.) PAGE 16
-- IA64 --
PLGRP_TABLE 0DE00000 0DE0FFFF 00010000 ( 65536.) PAGE 16 OVR,REL,GBL,NOSHR,NOEXE, WRT,NOVEC,NOMOD
PWASH_QUE_BOT 0DE10000 0DE10003 00000004 ( 4.) OCTA 4 OVR,REL,GBL,NOSHR,NOEXE, WRT,NOVEC,NOMOD
PWASH_QUE_TOP 0DE10010 0DE10013 00000004 ( 4.) OCTA 4 OVR,REL,GBL,NOSHR,NOEXE, WRT,NOVEC,NOMOD
SPAT_MNG_VAL_TABLE 0DE20000 0DE3FFFF 00020000 ( 131072.) PAGE 16 OVR,REL,GBL,NOSHR,NOEXE, WRT,NOVEC,NOMOD