stan@SUN-VALLEY.STANFORD.EDU (08/08/90)
You should get yourself on the VxWorks Exploder mailing list. There are a number of people struggling with useing g++ and VxWorks. I've appended a few representative exploder exchanges. There's more; check the exploder archives for details. (The first included message below explains how the exploder works). -- Stan Schneider stan@sun-valley.stanford.edu ----- Begin Included Message ----- >From @LBL.Gov:sypko@rtsg.ee.lbl.gov Wed Nov 22 09:47:27 1989 Return-Path: <@LBL.Gov:sypko@rtsg.ee.lbl.gov> Received: from LBL.Gov by sun-valley.Stanford.EDU (4.0/inc-1.0) id AA07379; Wed, 22 Nov 89 09:47:25 PST Received: from rtsg.ee.lbl.gov by LBL.Gov with INTERNET ; Wed, 22 Nov 89 09:36:39 PST Date: Wed, 22 Nov 89 09:38:34 PST >From: sypko@rtsg.ee.lbl.gov (Sypko Andreae) Message-Id: <891122093758.02p@rtsg.ee.lbl.gov> Subject: VXWExplo how to To: vxwexplo@LBL.Gov Cc: sypko@rtsg.ee.lbl.gov Status: RO WELCOME TO THE VXWORKS USERS EXPLODER: 'vxwexplo@lbl.gov' This message is to welcome you to the VXWExplo, tell you how to use it, and to ask you for some information. So please respond to me (sypko); don't repond to VXWExplo please! If you have some VxWorks related news you would like to convey, or if you need help from or have information for the users group then leave a message addressed simply to: vxwexplo @ lbl.gov and some 50 people will get your message. That is all there is to it! Please send a message to sypko@rtsg.ee.lbl.gov giving your name, mailing address, voice phone, FAX number, and a few lines of your area of interest, systems used etc. The information will be fed in a little database which will report to you occasionally. A few addresses we were not able to resolve. If you know of someone who is not in the current VXWExplo distribution list (malias) and would like to be, have him/her contact me. Sypko Andreae, UCLBL, (415) 486-6411 UCLBL, Mailstop 46A, Berkeley, CA 94720 e-mail: sypko@rtsg.ee.lbl.gov ----- End Included Message ----- ----- Begin Included Message ----- >From @Csa1.LBL.Gov:thor@thor.UCAR.EDU Fri Jan 26 07:45:25 1990 Return-Path: <@Csa1.LBL.Gov:thor@thor.UCAR.EDU> Received: from Csa1.LBL.Gov by sun-valley.Stanford.EDU (4.0/inc-1.0) id AA07547; Fri, 26 Jan 90 07:45:24 PST Received: from ncar.UCAR.EDU by Csa1.LBL.Gov with INTERNET ; Fri, 26 Jan 90 07:25:32 PST Received: from thor.ucar.edu by ncar.ucar.EDU (5.61/1.00.UUCP-MOD.8-11-85) id AA08029; Fri, 26 Jan 90 08:28:09 MST Date: Fri, 26 Jan 90 08:28:07 MST >From: thor@thor.UCAR.EDU (Richard Neitzel) Message-Id: <9001261528.AA09924@thor.UCAR.EDU> Received: by thor.UCAR.EDU (4.0/1.00.UUCP-MOD.8-11-85) id AA09924; Fri, 26 Jan 90 08:28:07 MST To: vxwexplo@Csa1.LBL.Gov Subject: ANSI C & C++, etc. Status: RO Now that ANSI C is the 'coming wave', what is on tap for 'ANSI-fying' VxWorks? I have edited some of the header files, adding the function prototypes. However, unless WRS starts supplying ANSI header files, I'll have to repeat the effort every time there is an upgrade. I realize that the old style headers work fine for ANSI C, but I have another reason for wanting them - C++. This forces the use of function prototypes. Of course this adds another set of requirements - for one, functions that take no arguements must be declared as foo(void). For another, C++ 2.0 requires special effort to avoid name mangling. In any case, here are some questions that you might be able to answer: 1> What is the legal status of edited WRS header files? Since they are copywrited by WRS, would they be willing to allow headers modified for ANSI C to be shared with other sites? If so how? Via the archive, on a personal basis, as context diffs, etc. Or can we expect WRS to do this work in the immediate future? 2> Following up 1, what is the WRS position on converting to ANSI C? 3> What are others out there doing with C++ and VxWorks? What C++ are you using? (I'm using g++ 1.36.3) What have been your experiences? I've implemented counting semaphores and found it extremely simple and efficient. (But that's all I've done for now!) OK, now my other topic - Where is VxWorks debugging headed? Currently I'm using dbxWorks and I have no complaints about it's functionality, but I do have some questions about the wisdom of reliance on Sun for my VxWorks' debugger. This is going to become more important when Sun finally orphans my poor Sun-3s. Besides, I would like to look at other vendor platforms for development, but I love having a debugger. Also, dbxWorks (I may be misinformed here) apparently only supports 680x0 targets. If I may be so bold, I suggest that what is required is something akin to the gnu debugger gdb, which can be built to handle a number of different targets. Granted any single copy of gdb is limited to a single CPU type, but I'm willing to have multiple versions if needed. Now, I believe that gdb already has hooks in it to allow implementation of remote debugging, so perhaps some one with time to spare could do a port that would handle VxWorks. OR perhaps WRS is going to have something real soon now. ------------------------------------------------------------------------------- Richard Neitzel National Center For Atmospheric Research Box 3000 Boulder, CO 80307-3000 303-497-2057 thor@thor.ucar.edu Torren med sitt skjegg Thor with the beard lokkar borni under sole-vegg calls the children to the sunny wall Gjo'i med sitt shinn Gjo with the pelts jagar borni inn. chases the children in. ----- End Included Message ----- ----- Begin Included Message ----- >From @Csa1.LBL.Gov:thor@thor.atd.ucar.EDU Mon Apr 23 07:56:55 1990 Return-Path: <@Csa1.LBL.Gov:thor@thor.atd.ucar.EDU> Received: from Csa1.LBL.Gov by sun-valley.Stanford.EDU (4.1/inc-1.0) id AA26095; Mon, 23 Apr 90 07:56:54 PDT Received: from ncar.UCAR.EDU by Csa1.LBL.Gov with INTERNET ; Mon, 23 Apr 90 07:51:34 PDT Received: from thor.atd.ucar.edu by ncar.ucar.EDU (5.61/ NCAR Central Post Office 04/10/90) id AA22505; Mon, 23 Apr 90 08:49:56 MDT >From: thor@thor.atd.ucar.EDU (Richard Neitzel) Message-Id: <9004231449.AA20875@thor.atd.ucar.EDU> Received: by thor.atd.ucar.EDU (5.61/ NCAR Mail Server 04/10/90) id AA20875; Mon, 23 Apr 90 08:49:50 MDT To: rjn@snowbird.labs.tek.com Cc: vxwexplo@Csa1.LBL.Gov Subject: Re: C++ and VxWorks In-Reply-To: Your message of Wed, 18 Apr 90 13:07:42 -0700. <9004182007.AA00208@snowbird.LABS.TEK.COM> Date: Mon, 23 Apr 90 08:49:49 -0600 Status: RO > Anyone using C++ and VxWorks? Comments, warnings, suggestions? > Well, I'm using C++ with VxWorks and so far I'm pleased. I've been using the GNU C++ compiler, g++ version 1.37. About the only thing that I've noted as a "problem" is that one must create one's own new and delete routines that must be downloaded prior to loading g++ code. Simple, but it tripped me up the first time. Of course, including calls to VxWorks functions involved some non-trivial typing, since the WRS headers are not ANSI style and do not include most functions anyway. I now have about 90% of the functions prototyped. Since g++ is C++ 2.0 compliant, I also created headers for g++ that use the extern "C" syntax to use the ANSI headers. (BTW, these are in the archive as c++headers.p1/2.) As far as ease of use with VxWorks goes, I've found it simple. So far I've implemented several simple classes (ring buffer, local event flags, "pipes") and am currently using g++ to develop a high speed radar display. Since we currently trying to benchmark variuos hardware for the display, C++ has proven extremely valuable, since I can make modifications to isolated sections cleanly and safely. Performance has not been a problem to date. Inline functions are a help here. The only time I have used g++'s inline assembler syntax was for floating point math functions. My own benchmarking shows that my C++ ring buffers are faster then the WRS equivalent. Of course, this isn't strictly a C++ evaluation, since other C++ compilers may produce better or worse code. > How about the long symbol names? So far the only problem has not been the length of the names, but rather the tediousness of determining how C++ has mangled them and then typing that whole mess in. As a strictly lazy way of handling this I declare all the function names that I intend to invoke interactively to use C linkage, preserving the exact function name ( the extern "C" syntax again). > How about static member constructors and global object constructors? Haven't tried the former. The latter is a problem that I haven't taken the time to address. g++ does produce code to global object construction, but since it's execution is normally done under UNIX by the task's startup code, one needs another way to invoke it. What probably needs to be done is to grab the UNIX code for this and hack it to suit VxWorks. The only true problem I have with using C++ for VxWorks development is the lack of debugger support. However, since WRS is using gdb as the porting base for their debugger and gdb understands g++, this problem should soon be moot. All in all, I'm planning on shifting the main thrust of development work here from C to C++. ---------------------------------------------------------------- Now it's my turn to ask questions: 1> Has anyone ported streams to VxWorks? Or is anyone working on this? 2> Would you please submit the result to the VxWorks Archive. Rich N. ----- End Included Message ----- ----- Begin Included Message ----- >From @Csa1.LBL.Gov:thor@thor.atd.ucar.EDU Tue Jun 19 08:10:26 1990 Return-Path: <@Csa1.LBL.Gov:thor@thor.atd.ucar.EDU> Received: from Csa1.LBL.Gov by sun-valley.Stanford.EDU (4.1/inc-1.0) id AA24937; Tue, 19 Jun 90 08:10:25 PDT Received: from ncar.UCAR.EDU by Csa1.LBL.Gov with INTERNET ; Tue, 19 Jun 90 07:56:24 PDT Received: from thor.atd.ucar.edu by ncar.ucar.EDU (5.61/ NCAR Central Post Office 04/10/90) id AA03225; Tue, 19 Jun 90 08:24:02 MDT >From: thor@thor.atd.ucar.EDU (Richard Neitzel) Received: from surt.atd.ucar.edu by thor.atd.ucar.EDU (5.61/ NCAR Mail Server 04/10/90) id AA25009; Tue, 19 Jun 90 08:23:58 MDT Date: Tue, 19 Jun 90 08:23:53 MDT Message-Id: <9006191423.AA01166@surt.atd.ucar.edu> Received: by surt.atd.ucar.edu (5.61/ NCAR Mail Client 04/10/90) id AA01166; Tue, 19 Jun 90 08:23:53 MDT To: vxwexplo@Csa1.LBL.Gov Subject: C++/G++ initialization Status: RO Well, I think I've found a way to get global objects to initialize themselves that doesn't bend the rules of C++ too far. Actually I came up with two schemes. The first is to simply call the constructor directly - ... class dummy { ...... dummy(int); ..... dummy D; mycode() { D.dummy(12); .... This works, but it means adding a reference to each global as it is added to the code. Further, g++ generates a code fragment that handles your globals' initialization, so this is "duplicated" code. The second method is very compiler dependent. I have only done this under g++-1.37, so be warned! On a Sun-3: G++ generates a stub "__GLOBAL_$I$?", where ? is the name of the first global object in the file. Likewise the destructor stub is "__GLOBAL_$D$?". To use them simply insert the lines: asm("jbsr __GLOBAL_$I$whatever"); or asm("jbsr __GLOBAL_$D$whatever"); as needed. On a Sun-4: G++ generates a different stub name - __GLOBAL_$D$file, where file is the name of the file containing the code, with '.' converted to '_'. The asm lines are: asm("call __GLOBAL_$I$whatever,0") asm("nop"); or asm("call __GLOBAL_$D$whatever,0") asm("nop"); as needed. Examining the assembler output on your system should yield the correct call for that architecture. This can be made into a very simple constructor/destructor wrapper around one's code. You just put all global objects into a single header file and then have an entry routine that calls the constructor stub before calling the main code body and the destructor stub on exit. This also helps to preserve the C++ convention, whereby globals are guarnteed to be initialized before the main routine is entered. Now we can only hope that the WRS debugger, since it's based on gdb, will understand g++ in the VxWorks environment. Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn. ----- End Included Message ----- ----- Begin Included Message ----- >From @Csa1.LBL.Gov:scotth@rocco.labs.tek.com Wed Jun 20 11:13:01 1990 Return-Path: <@Csa1.LBL.Gov:scotth@rocco.labs.tek.com> Received: from Csa1.LBL.Gov by sun-valley.Stanford.EDU (4.1/inc-1.0) id AA08065; Wed, 20 Jun 90 11:13:00 PDT Received: from RELAY.CS.NET by Csa1.LBL.Gov with INTERNET ; Wed, 20 Jun 90 10:52:25 PDT Received: from tektronix.tek.com by RELAY.CS.NET id aa11582; 20 Jun 90 13:52 EDT Received: by tektronix.TEK.COM (5.51/7.1) id AA24721; Wed, 20 Jun 90 10:55:18 PDT Received: from rocco.LABS.TEK.COM (rocco.TEK) by tekirl.labs.tek.com (4.0/7.1) id AA26442; Wed, 20 Jun 90 10:41:26 PDT Received: from localhost.TEK by rocco.LABS.TEK.COM (4.0/7.1) id AA07713; Wed, 20 Jun 90 10:51:38 PDT Message-Id: <9006201751.AA07713@rocco.LABS.TEK.COM> To: vxwexplo@Csa1.LBL.Gov Subject: Re: C++/G++ initialization In-Reply-To: Your message of Tue, 19 Jun 90 08:23:53 -0600. <9006191423.AA01166@surt.atd.ucar.edu> Date: Wed, 20 Jun 90 10:51:37 -0700 >From: scotth@rocco.labs.tek.com Status: R We've been doing it the second way, more or less. If others are interested, I'll see what I can do to put it into the archives. We've hacked a couple versions of the g++ compiler driver. One runs on Sun3s and the other on Sun4s. They're both called g++vx and emit code for 680x0 targets. Starting point is g++-1.37. G++vx runs _collect_ on all object files and produces code that is assembled and linked with those object files. This is nice for a couple of reasons: it's all automated plus it handles libraries, which for us is very important. Another libraries-related motivation for g++vx: we have to be very careful about the libraries we use. We own or license all code that we use in products. We don't want to accidentally use any Sun or FSF (libg++ or gnulib) libraries for this reason. G++vx takes care of this for us by preventing default linking with libc.a, libg++.a, etc.. For what it's worth: we also have gccvx drivers in the same vein, except that they (obviously) don't run _collect_. Plus we have gdbvx, which is the name we give to our 680x0 cross-debugger that runs on Sun4s. It is not the same as the WRS debugger. It is more useful for low-level source debugging, e.g. interrupt handlers, which is important to anyone bringing up VxWorks on a proprietary platform. Plus it can be configured to operate using a broader variety of interfaces. Are these things interesting to anyone else? GDB caveat: it's not clear yet whether I can give away any code that runs on the target system. Ref: gdb, this is a small (less than 2K) monitor that gdb uses instead of ptrace. Without it, you'd have to write your own. Scott Herzinger scotth%crl.labs.tek.com@relay.cs.net Computer Research Lab, Tektronix, Inc. PO Box 500 MS 50-662, Beaverton, OR 97077 ----- End Included Message -----