Gpc

gpc@gnu.de

5400 discussions

Re: Null characters in strings
by Morton, John 08 Sep '10

08 Sep '10

My thanks for confirming that writeln is not implemented using C's printf function (I can't remember where I got that idea) and that gpc's writeln can send all 256 characters (absolutely necessary to handle binary time as a string). On reflection I realize I have misstated our problem. But I think I also have a work-around for it. The issue is that the supplied library returns the time as a 32 bit binary value. The problem is essentially how to coerce the 32 bits into a corresponding 4 character gpc string. (BTW, they are the first 4 bytes of every message sent by our application). I had hoped that the coercion (effectively a type cast) would be easy to accomplish within Pascal. I then thought about variant records but that did not seem feasible. I have since realized that the conversion could be done where we define the interface to the external routine. In the Pascal function definition use a 4 character fixed length string for the time field and have the linker map that string to the corresponding 32 bit value field used by the library (probably by using pass-by-address, possibly pass-by-value). Not a pure Pascal approach but a practical one - as long as you are well aware of the pitfalls. (In the "pure" approach the Pascal interface parameter would be a 32 bit unsigned value that gets converted/mapped by Pascal to the corresponding 4 byte string). Anyone have any thoughts on this? Have I have missed a simpler approach? John. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Frank Heckenbach Sent: September 3, 2010 05:16 PM To: gpc(a)gnu.de Subject: Re: Null characters (& string Morton, John wrote: > We have encountered an unexpected implementation issue with gpc, one > that probably affects all languages implemented using C/C++: The > mapping of Pascal writeln (etc.) statements to "equivalent" C/C++ string > handling code. Others have replied already, but I can confirm that GPC does not use printf etc. internally to implement WriteLn, if that's what you mean. > Stated more generally, is there a pure gpc Pascal way to send > ("writeln") strings that can contain any/all of the 256 8 bit characters > (especially the null) - an approach that does not require retyping our > string definitions? Of course, any such way is not pure Pascal in the sense of ISO Pascal or so. Text files (WriteLn) are not really meant for binary data, though it works with GPC, and is as portable as GPC is, and probably works with some other compilers as well. The official Pascal way would be a "file of Char" (though ISO Pascal doesn't even guarantee that the NUL character is part of the character set), where you'd need to read/write every character individually. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

Null characters (& string implementation) in gpc
by Morton, John 03 Sep '10

03 Sep '10

We have encountered an unexpected implementation issue with gpc, one that probably affects all languages implemented using C/C++: The mapping of Pascal writeln (etc.) statements to "equivalent" C/C++ string handling code. We have not found a pure (Pascal-only) way to use gpc writeln (etc.) statements to send strings that must include null characters (in our case as part of a 4 byte binary time). The problem is that the implementation of the mapped C/C++ function prematurely terminates a message at the null, preventing the message from being transmitted properly. The impact on us is that whenever any byte of the time rolls over a service outage results - with the length of the outage depending upon which byte rolls over. We have since kluged a way around the issue but would much prefer a pure Pascal (=portable) solution. In our case the message must be sent as one complete entity, meaning separating the string into multiple "writeln" statements is not possible. (This would be an awkward approach if/when (multiple) nulls can appear anywhere in the string). Stated more generally, is there a pure gpc Pascal way to send ("writeln") strings that can contain any/all of the 256 8 bit characters (especially the null) - an approach that does not require retyping our string definitions? Any ideas out there about how to do this? Thanks.

4 3

Re: Null characters (& string implementation) in gpc
by Morton, John 03 Sep '10

03 Sep '10

Bonjour Maurice, I can't test gpc until I build "Hello world" (or "bug") so your results are great news for us. Our problem may have something to do with the FAA library and the way we had to link it to our code. More likely it's because we have a quite old version of gpc and the problem we encountered was fixed in a subsequent release. We'll see if the problem disappears after we rebuild our application using the new version of gpc (once I get it going). Merci. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Maurice Lombardi Sent: September 3, 2010 01:29 PM To: gpc(a)gnu.de Subject: Re: Null characters (& string implementation) in gpc Le 03/09/2010 17:23, Morton, John a écrit : > We have not found a pure (Pascal-only) way to use gpc writeln (etc.) > statements to send strings that must include null characters (in our > case as part of a 4 byte binary time). The problem is that the > implementation of the mapped C/C++ function prematurely terminates a > message at the null, preventing the message from being transmitted > properly. > I do not understand. The following test program works as expected: program bug; var s: string[255] = 'hello >'+chr(0)+'< world'; begin writeln(s); end. there is an unprintable character between the two > < and redirecting the output to a file which can be examined with a binary editor shows that this character is indeed a null. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

Why GPC? (was: GPC linker errors - help needed)
by Morton, John 02 Sep '10

02 Sep '10

Quite reasonable questions. And No, you didn't miss anything. Yes, we need to use static libraries/objects that we can place under configuration control. And static linking is mandatory for us. That's why I have used "rpm2cpio" to extract the 3 objects from "glibc-devel" that are used by gpc. Now I just have to figure out how to get gpc to use these 3 files and how to split gpc into separate compile and link phases and also get gpc to place the object files into their own permanent folder. Once that is done I should be able to rebuild our application on RHEL 5.4. Any hints here would be greatly appreciated. I agree with your point about commercial software but the choice of O/S, compiler, etc. was determined by the FAA, not us. They also provide us with a special purpose library that we must use (link to) when interfacing to their systems. That library pretty much forces us to use gpc and/or other gnu-based tools/compilers (gcc, gnat, etc). Gpc is being used for compatability to the library and because that is what was used to port our Pascal interface code (originally developed for HPUX in the mid 90s) to 32-bit RHEL. The reason behind behind what we are doing is that the FAA is moving a system we use to 64-bit RHEL5.4. The nature and importance of this system means we must move in lockstep with them. Part of our effort requires porting (for the second time) the existing code and development tools. While the current 32-bit executable should run without problems on RHEL5.4 we will have to maintain and upgrade this software for many years. BTW, I hope everyone understands that I have to play Devil's Advocate and think of the worst possible outcome that would occur if all the holes in the "Swiss Cheese" model line up. I only handle one of many slices; if any other slice blocks the hole in my layer then there is no safety issue. -----Original Message----- From: Hiltibidal, Rob [mailto:Rob.Hiltibidal@argushealth.com] Sent: September 1, 2010 05:10 PM To: Morton, John Subject: RE: GPC linker errors - help needed I think I missed something here... Why not use static libraries at this point? In all honesty if its safety/life-critical systems why not use commercial software that is supportable?

1 0

Re: GPC linker errors - help needed
by Morton, John 01 Sep '10

01 Sep '10

The reality of working with safety/life-critical systems means it very dangerous for us to use shared libraries. I understand the point about dependencies and the concerns expressed about extracting object files. But in my world the concerns are precisely opposite. It is safe to extract/use an object file (which can be properly controlled) and extremely unsafe to use a shared library (because other applications may "update" the library). BTW, Extracting the objects from the library shouldn't matter. If the object files were created as expected, all external references/definitions that they need will be satisfied during the link phase. Besides, if the object files do have dependency problems the application will not link - which is much, much safer than the standard situation. In my world a change to a shared library automatically destroys application certification - and the change can make every application that uses that library dangerous to the public. My problem right now is the dependency tree prevents the installation of "glibc-devel". However it looks like I can use the RPM "--nodeps" option to force Red Hat's "glibc-devel" package to install on my system. A better approach seems to be to use "rpm2cpio" (see http://www.rpm.org/max-rpm/s1-rpm-miscellania-rpm2cpio.html) to do the extractions. Has anyone tried this tool? If the "rpm2cpio" approach doesn't work we will probably have to force the install and handle the "glibc-devel" package like any other non-gpc library, see below. To meet our safety requirements we will have to place copies of the 3 object files - and all other non-gpc items (shared files/libraries, tools, etc.) used to build the application - into non-shared (= non-standard) locations, then instruct the linker to look for these files in their new location. And everything involved (including all gpc components) will be placed under configuration control. The end result is that our installation of gpc would become "Stand-Alone" and immune to changes to shared software. This also seems to be the easiest way to make use of the "shared" files while still meeting our safety (and other) requirements. Critically for us, this approach also ensures that several years from now that nothing has changed and that we can recreate an absolutely identical executable of our application, starting from nothing. The necessity to override standard locations with non-standard ones is another reason why it is important for gpc compiles to be separated into totally separate compile and link phases (e.g. two command files, normally invoked automatically, one after another). I suspect separating the gpc command into two separate compile and link command files is more complicated than just putting the commands (displayed by gpc -v) into separate files. For instance I don't see "hello.o" being passed to the "collect2" (the linker?) command and there also is the issue of how to handle/pass the temp files used by gpc. Does anyone have any experience in doing this? Thanks. -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 27, 2010 05:04 PM To: GNU Pascal mailing list Subject: Re: GPC linker errors - help needed On 27 Aug 2010, at 22:24, Morton, John wrote: > As expected "glibc.i686" was preinstalled. I tried installing the i386 > and x86_64 Red Hat rpms for "glibc-devel". Both rpms reported some > unsatisfied dependencies. To make a long story short, in both cases the > geometric growth of the dependency tree looks like it will eventually > force all of the gcc C compiler to be installed. > Maybe it's my non-C background but this hidden 3 file dependency (upon > C) seems unreasonable given that all that gpc needs (see output below) > is for those object files to be visible to the ld linker (assuming these > object files are not dependent upon other files). I would strongly recommend to simply install all dependencies. While things *may* work fine with just those files, they may just as well not for one reason or another. You can only make things more difficult for yourself by trying to circumvent the the dependencies of those packages. Jonas

1 0

GPC linker errors - help needed
by Morton, John 28 Aug '10

28 Aug '10

As expected "glibc.i686" was preinstalled. I tried installing the i386 and x86_64 Red Hat rpms for "glibc-devel". Both rpms reported some unsatisfied dependencies. To make a long story short, in both cases the geometric growth of the dependency tree looks like it will eventually force all of the gcc C compiler to be installed. Maybe it's my non-C background but this hidden 3 file dependency (upon C) seems unreasonable given that all that gpc needs (see output below) is for those object files to be visible to the ld linker (assuming these object files are not dependent upon other files). Here is what I'd like to do: - Place copies of the 3 object files (crt1.o, crtl.o, ctrn.o) into their own folder or my application folder (or in "/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6" since that folder already contains other "crt" files such as "crtbegin.o") then set up the linker search path appropriately. - Separate the gpc compile and link steps (using makefiles for each phase). - Compile each of the 70+ source files that make up our application separately then pass a makefile (i.e. a list of the corresponding object files) to the linker. - The object files need to be persistent across compiles (not deleted after the link stage). - Be able to pass/specify additional libraries and object files to the linker I expect this should be relatively straightforward except for extracting the 3 object files. What is the easiest way of getting these files? Also what Linux based SDKs, meeting the above requirements, are being used with gpc? We already use a Linux version of the Rational/IBM Clearcase and Clearquest config management tools. Hopefully there are some Linux based SDKs that are compatible with these CM tools. Thanks --- The results of my latest compile attempt: [etms@lxstn08 dev]$ gpc -v -Wa,--32 hello.pas Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/specs Configured with: ../gcc-3.4.6/configure --enable-languages=pascal Thread model: posix gpc version 20070904, based on gcc-3.4.6 /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.6/gpc1 -quiet -v hello.pas -quiet -dumpbase hello.pas -mtune=pentiumpro -auxbase hello -famtmpfile=/tmp/ccobDgZ4.gpa -version -o /tmp/cci6p6IZ.s GNU Pascal version 20070904, based on gcc-3.4.6 (i686-pc-linux-gnu) compiled by GNU C version 3.4.6. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Pascal Compiler PreProcessor version 20070904, based on gcc-3.4.6 as -V -Qy --32 -o /tmp/ccWia0MX.o /tmp/cci6p6IZ.s GNU assembler version 2.17.50.0.6-12.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-12.el5 20061020 /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.6/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 crt1.o crti.o /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/crtbegin.o -L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6 -L/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/../../.. /tmp/ccWia0MX.o -lgpc -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/crtend.o crtn.o /usr/bin/ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status [etms@lxstn08 dev]$ -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 25, 2010 03:40 PM To: GNU Pascal mailing list Subject: Re: GPC Assembler/linker errors - help needed On 25 Aug 2010, at 21:26, Morton, John wrote: > The gpc -v output shows that the compile now gets to the linker stage - > which complains that it cannot find crtl.o (and probably crt1.o and > crtn.o). These are part of the glibc-devel.i386 package. You have to install it on your compilation machines. It does not have to be installed on the staging/deployment machines (but glibc.i686 will have to be installed there). <<SNIP>> Jonas

3 2

Re: GPC Assembler/linker errors - help needed
by Morton, John 25 Aug '10

25 Aug '10

Thanks to the list (especially Jonas and Maurice) I've made progress. I am now able to log in as an unprivileged user ("etms") and run gpc (from "/home/etms/dev" which holds the "hello world" source code). The gpc -v output shows that the compile now gets to the linker stage - which complains that it cannot find crtl.o (and probably crti.o and crtn.o). Since none of these files are prefixed with a path it seems that the linker assumes they are in the current directory or are in the following default path (as one line - you can safely ignore the two "etms" folders): /usr/local/bin/:/usr/bin:/usr/X11R6/bin:/home/etms/bin: /opt/0V/bin:/opt/0V/bin/0pC:/etms/com:. I thought I saw the missing files somewhere but (assuming I've used "find" correctly) they aren't on my system at all. I did the search after deleting gpc-2.1 (from gnu-pascal.de) and then untarring (as root) "gcc-core-3.4.6.tar.tar" (from Brandeis) into it's default location (/usr/local/gcc-3.4.6). Shouldn't the 3.4.6 extraction have placed the 3 files in or under that directory? In theory all I need to do is update $PATH to include the appropriate directory - but which one is supposed to contain the three files? Or is there some other way (e.g. a command line option) to make the files visible to the linker? --- BTW, yum reports glibc 2.5-42 (i686 and x86_64 versions) and glibc-common 2.5-42 (x86_64 version only) but not libc (or libc-dev). My understanding is that this naming difference does not affect gpc (or anything else) on my Linux box. Finally, my thanks to Maurice for explaining the 64 bit situation. Luckily for me a 64 bit image is not (yet) an absolute requirement. Once I've got the 32 bit version working I'll be looking into building a 64 bit version from source code. John -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 25, 2010 07:11 AM To: GNU Pascal mailing list Subject: Re: GPC Assembler errors - help needed On 24 Aug 2010, at 23:35, Morton, John wrote: > Given that the "with gcc" binary tarballs are intended to be > stand-alone I am somewhat surprised that installing 32 bit > versions of "all dev packages (including libc-dev)" may be > needed. <<SNIP>> GPC programs by default use functionality from libc afaik, and hence to compile such programs you have to have the right libraries installed. <<SNIP>> > And am I correct in that a true 64-bit wide (x86_64) gpc Linux > compiler is not yet available? See Maurice' answer for this. > If so I expect I need to install the i686 version > of the "binutils" package. (yum only lists the x86_64 version and the > trace below implies that the 64 bit assembler is being used - this > seems to confirm my initial suspicion about a word length mismatch.) The x86-64 version of the assembler can also assemble 32 bit code. You just have to specify the correct parameter <<SNIP>> > [root@lxstn08 dev]# gpc -v -Wa -m32 hello.pas -Wa by itself does nothing. That parameter means "pass everything after the comma literally as option to the assembler". If you don't add anything, nothing will be passed. Use this instead: -Wa,--32 (including the comma, and no spaces in between) Jonas

4 4

Re: GPC Assembler errors - help needed
by Morton, John 25 Aug '10

25 Aug '10

Thanks to Jonas for the command line option suggestions. With them I am getting only 3 "push" (and no "pop") errors when I use the 2007 version of gpc (the 2002 version would not accept those options). Given that the "with gcc" binary tarballs are intended to be stand-alone I am somewhat surprised that installing 32 bit versions of "all dev packages (including libc-dev)" may be needed. And since I do not come from the C/Linux world (my background is primarily Fortan, Pascal, Ada) I'm not sure quite what is meant by "dev packages" - are we talking only libraries (libc-dev), tools (gcc, gpc, etc.) or something else? And which ones do I need, if any? (The issue may not be important, see below.) First: Am I correct in assuming that the "i686" versions are: a) 32-bit not 64-bit, and more importantly, b) NOT for the iTanium chip? And am I correct in that a true 64-bit wide (x86_64) gpc Linux compiler is not yet available? If so I expect I need to install the i686 version of the "binutils" package. (yum only lists the x86_64 version and the trace below implies that the 64 bit assembler is being used - this seems to confirm my initial suspicion about a word length mismatch.) Or, put another way, have I encountered a hidden assumption/pitfall that the "binary" stand-alone gpc packages expect binutils to always be 32-bits wide? BTW, The application has safety, security, configuration control and legal reasons that preclude the target machines from ever having anything installed that someone can use (e.g. compilers) to compromise the system. All development is done here, all that our field sites ever get are the binary executables in the form of an install package. And FYI, the entire program is: program hello; begin writeln('Hello, world!'); end; Compiling this (as root) using the -v option produced: [root@lxstn08 dev]# gpc -v -Wa -m32 hello.pas Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.6/specs Configured with: ../gcc-3.4.6/configure --enable-languages=pascal Thread model: posix gpc version 20070904, based on gcc-3.4.6 /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.6/gpc1 -quiet -v hello.pas -quiet -dumpbase hello.pas -m32 -mtune=pentiumpro -auxbase hello -famtmpfile=/tmp/ccA5rIAp.gpa -Wa -version -o /tmp/ccALeZVE.s GNU Pascal version 20070904, based on gcc-3.4.6 (i686-pc-linux-gnu) compiled by GNU C version 3.4.6. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Pascal Compiler PreProcessor version 20070904, based on gcc-3.4.6 as -V -Qy -o /tmp/ccKyOQdV.o /tmp/ccALeZVE.s GNU assembler version 2.17.50.0.6-12.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-12.el5 20061020 /tmp/ccALeZVE.s: Assembler messages: /tmp/ccALeZVE.s:9: Error: suffix or operands invalid for `push' /tmp/ccALeZVE.s:37: Error: suffix or operands invalid for `push' /tmp/ccALeZVE.s:51: Error: suffix or operands invalid for `push' [root@lxstn08 dev]# -----Original Message----- From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Jonas Maebe Sent: August 24, 2010 12:01 PM To: GNU Pascal mailing list Subject: Re: GPC Assembler errors - help needed On 24 Aug 2010, at 17:47, Morton, John wrote: > However when I compile the simplest possible "hello world" on RHEL 5.4 > (a fedora variant) I always get the following assembler errors: > > Error: suffix or operands invalid for "push" > Error: suffix or operands invalid for "pop" > > Does anyone know what is causing these errors - and/or a fix for them? This means that GPC is generating 32 bit code, but that it is being assembled as [64] bit code. Try passing the "-m32" parameter to gp/gpc, and if that does not work, try -Wa,-m32. Note that you may have to install 32 bit versions of all dev packages (including libc-dev) that you need, unless those are installed by default. <<SNIP>> Jonas

3 2

GPC Assembler errors - help needed
by Morton, John 24 Aug '10

24 Aug '10

We need to port and upgrade an existing gpc application from 32 to 64 bit Linux. (If you fly anywhere within/to/from North America your flight is indirectly affected - airport delays, etc. - by this application.) Naturally 64 bit gpc is our first choice for this task. However when I compile the simplest possible "hello world" on RHEL 5.4 (a fedora variant) I always get the following assembler errors: Error: suffix or operands invalid for "push" Error: suffix or operands invalid for "pop" Does anyone know what is causing these errors - and/or a fix for them? Background: The development system does NOT have gcc installed (since gcc cannot be installed on the machines that will be running our application). On the dev system I installed the 2002 gpc BINARY (the "gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz" file) from the gnu-pascal.de/binary/ web page. I also tried the 20070904 Linux binary downloaded from brandeis.edu and got exactly the same results. Both downloads are i686 versions. Will these versions work on x68_64 Linux variants? If not what version of GPC should I be using for XEON based systems? 32-bit i586? Or - and as the very, very last resort - should I install gcc 3.4.6 and, heaven help me, attempt to compile GPC from source code? For more details (including results from "gpc -v") see my original post of 2008-10-12 entitled "RE: hello world causes Linux assembler errors". Thanks. John Morton NavCanada Technical Services Centre 280 Hunt Club Road, Ottawa, Ont, Canada K1V 1C1 (613) 248-7184, mortonj(a)navcanada.ca

3 3

Re: Quo vadis, GPC?
by samiam＠moorecad.com 18 Aug '10

18 Aug '10

12 31

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc