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

Conference hydra::axp-developer

Title:Alpha Developer Support
Notice:[email protected], 800-332-4786
Moderator:HYDRA::SYSTEM
Created:Mon Jun 06 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3722
Total number of notes:11359

3549.0. "Redbrick System" by HYDRA::LNARAYAN () Fri Apr 25 1997 15:57

    Company Name :  Redbrick System
    Contact Name :  Hung
    Phone        :  408-399-7136
    Fax          :  
    Email        :  [email protected]
    Date/Time in :  25-APR-1997 14:56:29
    Entered by   :  L. Narayan
    SPE center   :  MRO

    Category     :  NT
    OS Version   :  V4.0
    System H/W   :  


    Brief Description of Problem:
    -----------------------------
Two similar routines gives different values for the same variable.
Since this was not clear I requested him to send a sample code.
T.RTitleUserPersonal
Name
DateLines
3549.1example codeHYDRA::LNARAYANFri Apr 25 1997 18:00134
From:	US6RMC::"[email protected]" "Hung Nguyen" 25-APR-1997 16:38:32.22
To:	"[email protected]" <hydra::axpdeveloper>
CC:	[email protected], hydra::axpdeveloper, [email protected]
Subj:	TLS variables on DEC Alpha NT.

Attention: Nari in TechSupport.

Please let me if you have any comments to the following scenarior.

Thanks,
-Hung.

Description: Global TLS variables on DEC Alpha NT do not behave the same as
on Intel Alpha NT. If the global TLS variable was defined twice in two
different files and linked with the /FORCE:MULTIPLE option, NT/VC++ on
DEC Alpha AXP treats it as a new variable while NT/VC++ on Intel platform
treats it as the same variable. This difference seems to exist only on tls
variables and not on other type of variables. Please see the simple example
with the output below:

/* main.c file */
#include <stdio.h>
#include <windows.h>
#include <winbase.h>

void sub();

__declspec(thread) HANDLE hfile = NULL; /*Global tls variable definition */
int x = 123; /* Global variable x */

main()
{
   char name[5] = "abc";
   hfile = CreateFile(
                      (LPCTSTR) name, 
                      GENERIC_READ | GENERIC_WRITE,
                      FILE_SHARE_READ | FILE_SHARE_WRITE, 
                      NULL, 
                      OPEN_ALWAYS,
                      FILE_ATTRIBUTE_NORMAL,
                      NULL
                      );
                      
   printf("I am in main: \n");
   printf("Handle created was : h = %d\n",hfile);
   printf("X should be 123    : x = %d\n",x);
   printf("===========================");
   sub();
}

----------------------------

/* sub.c file */ 
#include <stdio.h>
#include <windows.h>
#include <winbase.h>

__declspec(thread) HANDLE hfile; /* duplicate definition */
int x;                           /* already defined in main.c */

void sub()
{
printf("\nNow I am in sub routine: \n");
printf("Handle should be the same: h = %d\n",hfile);
printf("X should be still be 123:  x  = %d\n",x);
}

-----------------------------------------
OUTPUT on Alpha AXP NT:

D:\test>main
I am in main:
Handle created was : h = 76
X should be 123    : x = 123

Now I am in sub routine:
Handle should be the same: h = 0
X should be still be 123:  x  = 123

OUTPUT on Intel NT:

D:\test>
I am in main: 
Handle created was : h = 80
X should be 123    : x = 123

Now I am in sub routine: 
Handle should be the same: h = 80
X should be still be 123:  x  = 123

As you can see above, the handle created, h =76, in main was not visible in
the sub routine for DEC Alpha NT. The printf shows the handle to be 0 when
it should be 76.

======================================================
This is how it was compiled and linked:

E:\test>cl -c main.c sub.c
Microsoft (R) & Digital (TM) Alpha C
Copyright (C) Microsoft Corp 1984-19
Copyright (C) Digital Equipment Corp
All rights reserved.

main.c
sub.c
Generating Code...

E:\test>link /FORCE:MULTIPLE main.obj sub.obj
Microsoft (R) 32-Bit Incremental Linker Version 4.20.6164
Copyright (C) Microsoft Corp 1992-1996. All rights reserved.

sub.obj : warning LNK4006: _hfile already defined in main.obj; second
definition ignored
main.exe : warning LNK4088: image being generated due to /FORCE option;
image may not run

E:\test>


% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail13.digital.com by us6rmc.mro.dec.com (5.65/rmc-17Jan97) id AA02386; Fri, 25 Apr 97 16:33:26 -0400
% Received: from spunky.RedBrick.COM by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA26496; Fri, 25 Apr 1997 16:24:39 -0400 (EDT)
% Received: from hungpc (hungpc.RedBrick.COM [192.83.206.73]) by spunky.RedBrick.COM (8.8.0/mailhost-1.12) with SMTP id NAA27388; Fri, 25 Apr 1997 13:22:06 -0700 (PDT)
% Message-Id: <[email protected]>
% X-Sender: [email protected]
% X-Mailer: Windows Eudora Pro Version 2.2 (32)
% Mime-Version: 1.0
% Content-Type: text/plain; charset="us-ascii"
% Date: Fri, 25 Apr 1997 12:19:51 -0700
% To: "[email protected]" <hydra::axpdeveloper>
% From: Hung Nguyen <[email protected]>
% Subject: TLS variables on DEC Alpha NT.
% Cc: [email protected], hydra::axpdeveloper, [email protected]
    
3549.2updated the ISV with the following details...HYDRA::LNARAYANThu May 01 1997 12:59203
               <<< DECWET::DOCD$:[NOTES$LIBRARY]VISUAL.NOTE;1 >>>
                 -< Microsoft Visual C++ bug reports and kits >-
================================================================================
Note 506.0                  TLS global variable usage                  3 replies
HYDRA::LNARAYAN                                     125 lines  30-APR-1997 08:53
--------------------------------------------------------------------------------
    Hello
    
    This problem is reported by a partner, I have also tested this using 
    VC++ 4.0 and Alpha NT V4.0 to find that the TLS global variable value 
    is lost when using it from a function. Any suggestions? or Is this a
    known problem?
    
    Thanks In Advance
    Lakshminarayan
    
    PS: cross posted in DECWET::NT-DEVELOPERS
    ============================================================================
    sample code

Description: Global TLS variables on DEC Alpha NT do not behave the same as
on Intel Alpha NT. If the global TLS variable was defined twice in two
different files and linked with the /FORCE:MULTIPLE option, NT/VC++ on
DEC Alpha AXP treats it as a new variable while NT/VC++ on Intel platform
treats it as the same variable. This difference seems to exist only on tls
variables and not on other type of variables. Please see the simple example
with the output below:

/* main.c file */
#include <stdio.h>
#include <windows.h>
#include <winbase.h>

void sub();

__declspec(thread) HANDLE hfile = NULL; /*Global tls variable definition */
int x = 123; /* Global variable x */

main()
{
   char name[5] = "abc";
   hfile = CreateFile(
                      (LPCTSTR) name, 
                      GENERIC_READ | GENERIC_WRITE,
                      FILE_SHARE_READ | FILE_SHARE_WRITE, 
                      NULL, 
                      OPEN_ALWAYS,
                      FILE_ATTRIBUTE_NORMAL,
                      NULL
                      );
                      
   printf("I am in main: \n");
   printf("Handle created was : h = %d\n",hfile);
   printf("X should be 123    : x = %d\n",x);
   printf("===========================");
   sub();
}

----------------------------

/* sub.c file */ 
#include <stdio.h>
#include <windows.h>
#include <winbase.h>

__declspec(thread) HANDLE hfile; /* duplicate definition */
int x;                           /* already defined in main.c */

void sub()
{
printf("\nNow I am in sub routine: \n");
printf("Handle should be the same: h = %d\n",hfile);
printf("X should be still be 123:  x  = %d\n",x);
}

-----------------------------------------
OUTPUT on Alpha AXP NT:

D:\test>main
I am in main:
Handle created was : h = 76
X should be 123    : x = 123

Now I am in sub routine:
Handle should be the same: h = 0
X should be still be 123:  x  = 123

OUTPUT on Intel NT:

D:\test>
I am in main: 
Handle created was : h = 80
X should be 123    : x = 123

Now I am in sub routine: 
Handle should be the same: h = 80
X should be still be 123:  x  = 123

As you can see above, the handle created, h =76, in main was not visible in
the sub routine for DEC Alpha NT. The printf shows the handle to be 0 when
it should be 76.

======================================================
This is how it was compiled and linked:

E:\test>cl -c main.c sub.c
Microsoft (R) & Digital (TM) Alpha C
Copyright (C) Microsoft Corp 1984-19
Copyright (C) Digital Equipment Corp
All rights reserved.

main.c
sub.c
Generating Code...

E:\test>link /FORCE:MULTIPLE main.obj sub.obj
Microsoft (R) 32-Bit Incremental Linker Version 4.20.6164
Copyright (C) Microsoft Corp 1992-1996. All rights reserved.

sub.obj : warning LNK4006: _hfile already defined in main.obj; second
definition ignored
main.exe : warning LNK4088: image being generated due to /FORCE option;
image may not run

E:\test>

================================================================================
    
     
                  
    
================================================================================
Note 506.1                  TLS global variable usage                     1 of 3
HYDRA::CHIN                                          35 lines  30-APR-1997 13:26
--------------------------------------------------------------------------------

  RE: -1

  I tested the program on VC50 (RTM, V11.01.7050) and linker v5.01.7044,
  the problem was non reproducible.


C:\miller\vcxx>main
I am in main:
Handle created was : h = 76
X should be 123    : x = 123

Now I am in sub routine:
Handle should be the same: h = 76
X should be still be 123:  x  = 123

I got same warning messages at link time though:

sub.obj : warning LNK4006: _hfile already defined in main.obj; second
definition ignored
main.exe : warning LNK4088: image being generated due to /FORCE option;
image may not run


  I will verify if the problem is indeed reproducible on our VC4.2b system
  tomorrow.  If it is, there is two way we can fix this:
       1. ask ISV to upgrade to VC50
  or   2. provide a vc4.2b patch

  Which one is likely to happen? 

  
  Miller

~
================================================================================
Note 506.2                  TLS global variable usage                     2 of 3
DECWET::JO "Mary had a little lamb, with mint jelly" 18 lines  30-APR-1997 14:00
                         -< fix multiple declaration >-
--------------------------------------------------------------------------------
    hi miller,
    
    the right thing for the customer to do is to fix the multiple
    declaration.  that is the only thing that will guarantee him of
    consistent behaviour.  using /FORCE to produce an image regardless of
    the error is not safe.  behaviour of the image produced will be 
    unpredictable and inconsistent as demonstrated by the fact that v50 
    gives him the answer he wants and the previous version doesn't.  the 
    linker warnings will not go away unless the duplicate declaration is 
    fixed.
    
    to quote the documentation on the linker option for /FORCE
    "A file created with this option may not run as expected.  The linker
    will not link incrementally when the /FORCE option is specified."
    
    in other words, "USE AT YOUR OWN RISK"
    
    jo
================================================================================
Note 506.3                  TLS global variable usage                     3 of 3
DECWET::JO "Mary had a little lamb, with mint jelly." 4 lines  30-APR-1997 14:07
                                   -< oops >-
--------------------------------------------------------------------------------
    oops.  the previous reply was suppose to be addressed to the
    originator.  sorry.
    
    jo
    
3549.3need to fix multiple declarations or upgrade to VC5.0HYDRA::LNARAYANThu May 29 1997 12:127
    As per the response received form the visual notes confrence,
    
    The partner needs to fix the multiple declaration 
                         or
    should upgeade to VC5.0
    
    Informed the partner accordingly