Conference hydra::axp-developer

Dave called back and had another question.  He's having trouble doing
debugging on his code.  He has a main C routine and wants to step
into a C++ routine.  When he does this in the debugger, he gets a 
failure message:

	debuggee error in rst from dst
	cannot find corressponding rst
	session corruption

Is there a way to get around this problem.  What problems are introduced
to the symbol table from using C++ code in the debugger.

Gerrit

More questions:

1) In his compilation he's not getting any link errors
on a fork() call.  Is something like this implemented in
VMS now, or does he need to recode a different method.

2) His app uses named ports referenced through /etc/services
is there a way to get a named port in VMS?

3) Why are you handling all the VMS questions if it
isn't something you have experience in?  And [seriously
folks], "is there a way to pull yourself out of the loop
since you're not a VMS person; I know I had contact with
some other people with VMS knowledge, Chuck Newman for
instance."


Gerrit

From: David Partridge <[email protected]>
To: alpha-developer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Garrit: Call # 3621
Date: Thu, 15 May 1997 17:29:30 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Garrit,

Here is the set of errors I see when I start up the debugger: 

%DEBUG-E-INTERR, debugger error in DBG_RST_FROM_DST: could not find
corresponding RST or session corruption
%DEBUG-I-INITIAL, Language: C_PLUS_PLUS, Module: TEST
%DEBUG-I-NOTATMAIN, Type GO to reach MAIN program
%DEBUG-W-SRCNOSRCLIN, No source line for address: 0000000000030000

When I type Go, I get

%DEBUG-W-SRCNOSRCLIN, No source line for address: 00000000000320EC
break at routine MAIN

-----------------------------
Every file has been compiled with the command:

cxx/nolist/noopt/debug  test.cxx

Then placed into a library with the command:

library/replace mylib.a test.obj

Then linked with the command:

link/debug/exe=bindir:test.exe/nomap -
	libdir:mylib.a/lib/include=test.exe, -
	libdir:mylib1.a/lib, -
	uxcrtl/opt

where the file uxcrtl.opt has the line:

sys$share:ucx$rpcxdr_shr/share


I've tried to use the SET SOURCE command to set the source path to the
correct
directories, but this has no effect.  SHOW SOURCE shows that the path is
correct, but it still won't load the source files.

I have another executable that has a C front end.  When I run this in
the
debugger, the C code is visible, but as soon as I step into a C++ file, 
I cannot see the source.

-----------------------------
One other issue that arises has to do with the fact that we overload the
new operator in C++ in order to make it call calloc, and thus provide us
with memory that has been zeroed.  Simply overloading the generic new 
operator does not seem to work (it does on all Unix systems that we have
tried and on NT), so we have defined our own versions of __nw__FUi and
__dl__FPv.  This seems to work correctly, but means that we always get 
link warnings of the form:

%LINK-W-MULDEF, symbol DECC$__DL__XPV multiply defined 
	in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
%LINK-W-MULDEF, symbol DECC$__NW__XUI multiply defined 
	in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1

This doesn't seem to cause any problem, but we would prefer not to have
the warnings.  Is there a better method that we could use to ensure that
new returns zeroed memory?

------------------------------
And finally, the end product that we ship consists of a number of c++ 
executables, a large library of C++ objects, and some c stubs.  The
customer implements the C stubs, links with the C++ library we provide
and creates an executable that they redistribute to their customers.  We
require our customer to have C, but we do not want to require them to
have
C++, and their end customers shouldn't need either.  Is there a library
or a set of objects that we can incorporate into our library, that we 
can redistribute to our customer so that they can link with our C++
library
without requiring any of the C++ runtime on their system?  Also, do we
need to specify any special options when linking our C++ executables so
that they will use a static runtime and run on systems where C++ is not
installed.

Thank you for your help.

Dave Partridge
Dharma Systems, Inc
(603) 886-1400 x12
[email protected]

    I asked Dave to send me the sources and the compile commands for the
    c++ program.  I will try to recreate the debugger problem.
    
    Mark

From:	SMTP%"[email protected]" 20-MAY-1997 11:30:21.92
To:	alpha-developer <[email protected]>
Hi Mark,

Here are my little test routines.  P3.CXX is identical to P1.CXX, but the  class is commented out.  I execute build.com
to build them, then run P1.EXE and P3.EXE.  With P3.EXE I can see all the code in the debugger.  With P1.EXE,  when
I start the debugger, I get:

%DEBUG-E-INTERR, debugger error in DBG_RST_FROM_DST: could not find corresponding RST or session corruption
%DEBUG-I-INITIAL, Language: C_PLUS_PLUS, Module: P1
%DEBUG-I-NOTATMAIN, Type GO to reach MAIN program

When I step into the routine in P2 (for me the instruction to step into is:	00020118:        BSR        R26,#X000009)
I can see the code there.  (The results are the same, but it seems to be easier to step into the subroutine if I have
DBG$DECW$DISPLAY defined as " " so I don't enter the windowing mode.  Probably just because I'm not as familiar with the
windowing version of the debugger.)

Regards,
Dave Partridge
Dharma Systems, Inc.
(603) 886-1400 x12
[email protected]

======================================================= p1.cxx ==============================================================
#include <string.h>
#include <stdio.h>

class myclass 
{
public:
	int a;
	int b;

	myclass() {}
	~myclass() {}

};

int test();

int main()
{
	printf("This is the test routine with a class\n");
	return test();
}

======================================================= p2.cxx ==============================================================
#include <string.h>
#include <stdio.h>

int test()
{
	printf("This is the test routine without any classes\n");
	return 0;
}

======================================================= p3.cxx ==============================================================
#include <string.h>
#include <stdio.h>

/*
class myclass 
{
public:
	int a;
	int b;

	myclass() {}
	~myclass() {}

};
*/

int test();

int main()
{
	printf("This is the test routine with a class\n");
	return test();
}

======================================================= build.com ==============================================================
$cxx /NOLIST/NOOPT/OBJ=*.obj/DEBUG  p1.cxx
$cxx /NOLIST/NOOPT/OBJ=*.obj/DEBUG  p2.cxx
$cxx /NOLIST/NOOPT/OBJ=*.obj/DEBUG  p3.cxx
$link/debug/nomap p1.obj, p2.obj
$link/debug/nomap p3.obj, p2.obj

From:	HYDRA::AXPDEVELOPER "[email protected]" 20-MAY-1997 14:31:42.36
To:	SMTP%"[email protected]"
CC:	AXPDEVELOPER
Subj:	RE: Attn: Mark Schafer

Dave,

I'm setting up my system to reproduce your problem.  What version of C++
are you using.  I'm reading the V5.5 install. guide and it claims that there
is a special C++ debugger for OpenVMS.

Mark Schafer

From:	HYDRA::AXPDEVELOPER "[email protected]" 20-MAY-1997 14:42:52.16
To:	SMTP%"[email protected]"
CC:	AXPDEVELOPER
Subj:	RE: Attn: Mark Schafer

Dave,

In addition to finding out the version, I'd like to know if the version that
you are using has the cxxlink command?

cxxlink is layered on top of the VMS linker.  Besides linking your program,
cxxlink completes automatic template instantiation and ensures that the
Standard Template Library run-time support and exception handling run-time 
support are linked into your program.

Mark Schafer

From:	HYDRA::AXPDEVELOPER "[email protected]" 20-MAY-1997 16:15:24.40
To:	SMTP%"[email protected]"
CC:	AXPDEVELOPER
Subj:	RE: Attn: Mark Schafer

Okay, I verified it.  Don't use the normal debugger.  Only use the special
debugger that comes with the C++ kit.  You have to install it separately
and there is a system startup file that must be run.  Details are in the
C++ install guide.  Do you have the software and documentation?

Mark Schafer

From:	SMTP%"[email protected]" 21-MAY-1997 16:50:16.21
To:	alpha-developer <[email protected]>

Hello Mark,

    Thank you again for your help with the debugger.  Now that I can see 
    my code, I've managed to isolate my problem, although I have not yet
    solved it.  As I mentioned, we have a daemon which listens on a known
    port, accepts a  connection, then starts a child process to handle the
    connection and goes back to  listening on the port.  The problem I have
    is how to hand the connection off to  the child.

    Since this is portable code, the child process uses the IPC interface 
    (recv, send etc) for all its IO.  I could also use the IPC interface
    for the  daemon, but I don't know how to pass the socket off to the
    child in that case.  To work around this, our previous implementation, 
    which used Process  Software's TCP/IP, did the following:

Daemon: Uses QIO interface to listen on port and accept a connection
        Gets the device name of the new channel using sys$getdvi
	creates a mailbox
	creates a process connected to that mailbox
	waits for an ack from the child process through the mailbox
	writes the device name to the mailbox
	waits for a message from the child that it has the socket
	closes the mailbox
	dassigns the new channel
	loops to accept next connection

Child:  connects to the mailbox
	sends an ack
	reads the device name
	does a sys$assign on the device name to get a channel for the socket
	sends message to daemon that has socket
	closes mailbox
	handles connection using IPC calls, with channel returned from
              sys$assign used as the socket id

    This worked fine.  However, when using UCX on Alpha, I am unable to 
    use the IPC calls on the channel I have gotten from sys$assign.  I can
    read from  the socket without any problem using qio's, but recv returns
    -1.  I'm willing to  take any solution that will get me past this.  The
    two possibilities that come  to mind are a method to convert the
    channel from the sys$assign to a socket  number I can use IPC calls on,
    or a method of having the daemon use IPC calls and  somehow pass the
    socket off to the child.  If you have any ideas that might  help I
    would greatly appreciate it.

    To test the use of recv, you can use the files in ucx$examples.  Edit
    ucx$tcp_server_qio and add a call to recv right before the QIO to read 
    the message.  Then use ucx$tcp_client_qio to send a message.

=======================================================================  
======

    The second issue that I mentioned was that we overload new.  We do 
    this in order to route the memory allocation through calloc so that all
    the memory  we get is initialized to zero.  We do this by declaring the
    following functions: 

void  * operator new(size_t nbytes)
void  operator delete(void *ptr)

This works fine, but always generates the following link warnings:
%LINK-W-MULDEF, symbol DECC$__DL__XPV multiply defined
        in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1
%LINK-W-MULDEF, symbol DECC$__NW__XUI multiply defined
        in module DECC$SHR file SYS$COMMON:[SYSLIB]DECC$SHR.EXE;1

    Is there a better way for us to do this?  Our customers have to link 
    with our libraries, and we'd prefer that they not see any warnings.

=======================================================================  
=======

    Finally, there is the issue of how our product is used.  We distribute 
    a number of executables, with the code written in C++.  In addition, we
    send a  large library of our C++ code.  The customer implements a
    number of C stub  routines, then links them with our C++ library. 
    (This forms the client process  that the listening daemon passes the
    connection to.)  They then redistribute  our executable and their newly
    created executable to their customers.  The  issue we have is that we
    do not want to require out customers to have any C++  components on
    their system, nor should their customers need either C++ or C 
    components. What steps to we need to take so that our customers can
    link with our  C++ library without needing C++ components, and how do
    we need to create  our executables so that they do not need any runtime
    components.  On the  Unix systems, we generally achieve this by linking
    the executables  statically, and extracting a number of routines from
    the system C++ library and  including them in our library.  Can we take
    a similar approach on VMS?

=======================================================================  
=======
Thank you for your help.

Regards,
Dave Partridge
Dharma Systems, Inc
(603) 886-1400 x12
[email protected]

    Company Name :  Dharma Systems, Inc
    Contact Name :  Dave Partridge
    Phone        :  (603) 886-1400 x12
    Fax          :  
    Email        :  [email protected]
    Date/Time in :  23-MAY-1997 07:37:36
    Entered by   :  John Talatinian
    SPE center   :  MRO

    Category     :  VMS
    OS Version   :  
    System H/W   :  


    Brief Description of Problem:
    -----------------------------

Hello,

The application we are porting to VMS listens on a named port for a connection
request
from a client PC.  In our Unix version, we name this port by simply adding an
entry
in the /etc/services.  Then our daemon decides what port to listen to by
calling 
getservicebyname().  In looking through the documentation for UCX, the only
means
I have found for registering a service seems to be the SET SERVICE command,
however,
this command has an extensive amount of required information that is not
pertinent
to us (file, process_name, user_name).  Is there some other way that we can
name a 
port so getservicebyname can be used, or do we really need to use SET SERVICE? 
One
of the advantages of the /etc/services entry is that our customers can easily
make
multiple entries.  Since we accept the service name to listen to as a command
line
parameter to the daemon, this allows them to have multiple deamons running
listening
to different ports.

Thank you for your help.

Dave Partridge
Dharma Systems, Inc (Program Access Code: 127970)
(603) 886-1400 x12
[email protected]

Hi Mark,

Almost, but unfortunately, not quite what we need.  I'd found the vaxc$get_sdc
call today and took a look at it.  The problem is that this provides a way
to go from an IPC socket to a QIO channel.  We need to do the reverse.

Actually, it's not really true that we NEED to do the reverse.  What we need to
do is pass a socket from one process to another.  The only reason that I was
using the QIO interface at all was that the only way I could find to pass a 
socket was to pass the device name and have the receiving process do a sys$assign
on the device.  If there were a way for the daemon process to do the accept
using IPC and someone let the child process pick up that socket, then that would
be fine.

The child is a very large set of portable code, so I can't change it, it must use
IPC.  The daemon I have complete flexibility with, it can use QIO or IPC,
whatever
is necessary.

Perhaps there is another method.  How exactly do the Services that UCX supports
work?
Do we really need to have a process listening on the port, or is it possible to 
have any connect request to that port start a process, in which case we could go
directly to the child and simply bypass the daemon entirely.  On Unix we just add
a line to /etc/services to assign a port number to our known service name.  The
only equivalent to this that I've been able to find on VMS is the SET SERVICE
command,
which has a file, process_name and user_name attached.  Where on Unix I do the 
following:

add to /etc/services  the following line
dharma_port    1990/tcp

start daemon listening on dharma_port, daemon does accept, forks child to handle 
socket traffic, goes back to accept.


On VMS can we do something like:

SET SERVICE dharma_service/port=1990/file=mycommand.com/....

Then mycommand runs the child process directly.  If so, how does the child
process do
the accept to get the socket?

Or, is this not how the services work?  I wasn't looking to do this when I
scanned the
documenation, I was looking for a simple equivalent of adding a line to
/etc/services.
(Is there a simple equivalent?)  I'll go back and take a look at that
documentation
more closely.  Could you let me know if this might be a path worth following.

Thank you again for your help.

Dave Partridge
[email protected]

From:	HYDRA::AXPDEVELOPER "[email protected]" 27-MAY-1997 09:26:35.86
To:	SMTP%"[email protected]"
CC:	AXPDEVELOPER
Subj:	RE: ATTN: Mark Schafer

The advice that I received from the UCX folks is:

        When using UCX with VAX C or DEC C, OpenVMS channels (as from
        sys$assign) and socket descriptors are two totally different
        animals.  They may both look like small integers, but they are
        not the same thing and cannot be used interchangeably.

        Two alternatives:

        The UCX feature known as "auxiliary server" allows a new
        process to be created to handle each client connection that
        comes in.

	socket descriptors in the parent process are duplicated in a
        vfork/exec* created child process beginning with OpenVMS V7.0,
        
	Coming soon:

	For those users and ISV's which need to support earlier
        versions of OpenVMS, the DEC C V5.6 compiler offers an object
        library called DECC$CRTL.OLB which is equivalent to the OpenVMS
        V7.1 object library (including socket inheritance).  This library
        is available only as an object library whose objects are linked
        with the application.

Thanks,

Mark Schafer