Gpc May 2001

gpc@gnu.de

26 participants
40 discussions

GPC and GCC 3.0
by Vaclav Haisman 16 May '01

16 May '01

Hi, I wonder if gpc will work with GCC 3.0 release? Vaclav Haisman -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/IT d- s+:(+) a-- c++ UB+(++) P++(+++) L+ E W++ N+ o? K? w+ O? M-(--) V? PS(+) PE++ Y PGP t(+) 5? X R+@ tv+ b++ DI+ D+ G e h! r-(--) !z+ ------END GEEK CODE BLOCK------

2 1

Re: gpc on cygwin with dll's (fwd)
by Matthias Braun 16 May '01

16 May '01

On Wed, 16 May 2001, Prof. A Olowofoyeku (The African Chief) wrote: > On 16 May 2001, at 15:29, Matthias Braun wrote: > > [...] > > A typical line from allunit.pas is: > > var > > screen: BITMAP_ptr; asmname 'screen'; external; > > this produces a screen not found when linking the thing, however, linking > > the C files suceed. So I looked at the symbols with objdump -t -T, and saw > > that the C object files use __imp_screen instead of _screen, although C > > Declaration is also > > BITMAP *screen; > > > > So I tried to changed the code to > > screen : BITMAP_ptr; asmname '_impl__screen'; external; > > which linked ok, but produced crashing progs. After some investigation, I > > discovered, that these __imp_screen, aren't the global var itself but a > > pointer to the var. > > Yes. Isn't that what the "*" in the declaration means? No. It's a pointer to a pointer to a BITMAP. I missinterpreted C declaration stuff (There are complicated preprocessor things) The correct declaration is: extern __attribute__((dllimport)) BITMAP *screen; So the thing seems to be the dllimport. But when using dllimport with variables, gpc sometimes seems to do nothing (if attribute(dllimport) stands after asmname), or gets confused (if it stands direct after the var declaration). I tried to use it with functions and procedures and then it does the right thing: It adds a __imp__ in front of the symbol name. So this looks to me like a compiler bug. > > Am I doing something wrong or can't gpc handle dll stuff right? > > GPC can handle dll stuff quite fine. The entire Win32 API is dll-based, > and GPC programs can use the API with no problem. You need to make sure > that you are dereferencing the pointers where appropriate. But may also > need to attach the "stdcall" attribute to the DLL function imports. What > I do to simply it all is this; > > {$define Stdcall attribute(stdcall)} > {$define WINAPI(X) asmname X; Stdcall} > FUNCTION GetDC ( Wnd : HWND ) : HDC; WINAPI ( 'GetDC' ); > blah, blah .... Thanks, didn't know that. But Allegro Library consisted of 2 libs anyway: the all3936.dll and liballeg.a, and I link the liballeg.a with my programs, which seems to be a wrapper to the lib. I don't need to define the procedures and functions like this, it's working with a simpel "C;". Matze

1 0

Compiling latest gpc on latest cygwin
by Matthias Braun 16 May '01

16 May '01

Hello, I've got problems with compiling gpc snapshot from 12.5 and latest cygwin with gcc 2.95.3-4 I did like described in the faq, and I had some problems I solved: -There was no patch for gcc 2.95.3-4 so I took the one for 2.95.3 -GPLUSPLUS_INCLUDE_DIR and TOOL_INCDLUDE_DIR wasn't declared in gpcpp.c, I found an #undeclare in cygwin.h and deletet it. After that compiling worked, but if I use the compile now, the following appears: (gpc -v test.pas) Reading specs from /usr/lib/gcc-lib/i586-pc-cygwin32/2.95.3-4/specs gpc version 20010512, based on 2.95.3-4 (cygwin special) /usr/lib/gcc-lib/i586-pc-cygwin32/2.95.3-4/gpcpp.exe -lang-pascal -v -famtmpfile=/PlatteC/WINDOWS/TEMP/cc985291 -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010512 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -D_X86_=1 -D_X86_=1 -Asystem(winnt) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di586 -Dpentium -D__i586 -D__i586__ -D__pentium -D__pentium__ -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D_stdcall=__attribute__((__stdcall__)) -D_cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -isystem /usr/local/include -idirafter /usr/include -idirafter /usr/include/w32api test.pas /PlatteC/WINDOWS/TEMP/cca85291 GNU Pascal Compiler PreProcessor version 20010512, based on gcc-2.95.3-4 (cygwin special) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/include /include /usr/lib/gcc-lib/i586-pc-cygwin32/2.95.3-4/include /usr/include /usr/include /usr/include/w32api End of search list. /usr/lib/gcc-lib/i586-pc-cygwin32/2.95.3-4/gpc1.exe /PlatteC/WINDOWS/TEMP/cca85291 -quiet -dumpbase test.pas -version -famtmpfile=/PlatteC/WINDOWS/TEMP/cc985291 -o /PlatteC/WINDOWS/TEMP/ccb85291 GNU Pascal version 2.95.3-4 (cygwin special) (i586-pc-cygwin32) compiled by GNU C version 2.95.3-3 (cygwin special). GNU Pascal version is actually 20010512, based on gcc-2.95.3-4 (cygwin special) as -o /PlatteC/WINDOWS/TEMP/ccc85291 /PlatteC/WINDOWS/TEMP/ccb85291 gpc.exe: Internal compiler error in `do_spec_1', at p/gpc.c:4500 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

3 3

gpc on cygwin with dll's
by Matthias Braun 16 May '01

16 May '01

We're doing a project at school (a small game), because most pupils in my class only program in pascal, we have a project with mixed C / Pascal. As a gfx library we use allegro. This mix worked great under djgpp, but we wanted some tcp/ip networking, so I tried to port things to cygwin. (I'll publish the gpc allegro wrapper I wrote after the project) linking with windows gives some strange problems with global vars: A long description follows: A typical line from allunit.pas is: var screen: BITMAP_ptr; asmname 'screen'; external; this produces a screen not found when linking the thing, however, linking the C files suceed. So I looked at the symbols with objdump -t -T, and saw that the C object files use __imp_screen instead of _screen, although C Declaration is also BITMAP *screen; So I tried to changed the code to screen : BITMAP_ptr; asmname '_impl__screen'; external; which linked ok, but produced crashing progs. After some investigation, I discovered, that these __imp_screen, aren't the global var itself but a pointer to the var. This is bad, because it would mean to change all pascal files. C compiler seems to do this automagically. Am I doing something wrong or can't gpc handle dll stuff right? Matze

3 2

Re: Memory use problem
by david＠tcs01.demon.co.uk 16 May '01

16 May '01

In message <Pine.LNX.4.21.0105142130540.150-100000(a)rusty.russwhit.com> Russ Whitaker writes: > On Tue, 15 May 2001, Frank Heckenbach wrote: > [..] > > Another possibility: I recently read an article in the German c't > > magazin about glibc. If you're using it (most Linux systems do by > > now), you might be able to use its debugging facilities (look for > > mtrace() and $MALLOC_TRACE -- I hope there's something about it in > > the docs or on the net). > > > > Try info glibc. There's a node called "Allocation Debugging" with 4 > sub-nodes. > > Don't know about earlier releases, but it is in glibc-2.2.2 release. Thanks to Frank and Russ for those suggestions. MALLOC_TRACE, mtrace, and muntrace are also in glibc-2.1.3 (when I finally managed to get info libc to tell me anything). So ... I put a call to mtrace at the start of my message handling loop and a call to muntrace at the end of my message handling loop, in such a way that I turn the tracing on for exactly one pass though the loop. Then I ran the mtrace script on the resulting output ... I get 4008 unfreed blocks (that number is not relevant, except as an indication that there's a lot of memory allocation going on), all of them have been called from line 121 of rts/heap.pas. They are for varying memory sizes (a quick glance shows 0x1, 0xd, 0x21, 0x1e, 0x5e and an overwhelming majority for 0xa0). This is with the 20010512 GPC release. I think that source line is p:=GetMemPtr^(Size) in GPC_GetMem. Now what I need to know is where is this being called from (unless anyone is able to say immediately 'ah yes ...'). I'd like to be able to get a call stack listing under program control. Any suggestions on how to do this, please? -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

2 1

Reading boot sector of PC under Linux
by Martin Liddle 15 May '01

15 May '01

Does anybody have a code fragment to read the boot sector of a PC running Linux (Red Hat 6.2 if it matters)? -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

5 8

Re: Memory use problem
by david＠tcs01.demon.co.uk 15 May '01

15 May '01

In message <1B07E47F.20010506131757.FOO-5823.frank(a)g-n-u.de> Frank Heckenbach writes: > > Simply using the unit HeapMon should show some report about > non-released pointers at the end of the program. The unit also > provides a function to generate such a report at an arbitrary point > during a program run and to an arbitrary file. > > The report contains the caller address (which can be turned to > source lines using addr2line) which might help find the leaks. Frank, Thank you, I've now downloaded version 20010512, and tried the new HeapMon. It is very useful. Unfortunately, what it seems to show is that my problem is not with non-released pointers. The general structure of this program is (in a sort-of pseudo-code): begin allocate_shared_memory; use HeapMon to report non-released pointers; (*1*) while true begin wait for a message on a System V IPC message queue; process the message; (* a lot of code, usually involves writing a new file*) use HeapMon to report non-released pointers; (*2*) end; (*never gets here - program is terminated by a signal(2) from some other process*) end. I see no difference between the report from HeapMon at point (*1*) and the reports from HeapMon that are generated after each message is processed at point (*2*). Each of them shows the 4 separate pieces of memory that are allocated by new in allocate_shared_memory. However, as the program runs (under Linux) I see the Vsize (and RSS) increasing. I suspect that my problem is allocation within routines from the C run-time libraries that my low-level code is calling, or (possibly) allocation within the GPC RTS. My question now is, what else can I try to see what is being allocated and not released at these lower levels. Is electric fence the tool to use (and if so, how well does it work with GPC)? Anyone any other suggestions? -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

3 2

GRX for GPC: Demo files?
by Markus Gerwinski 12 May '01

12 May '01

Hi folks, are there any demo files for usage of the GRX GNU Pascal interface? Especially I need to know how to just initialize a GRX program - in X11 or - from a shell. Since the Pascal interface of grSetMode has another parameter list as the original function in C, this is a non-trivial problem. Further, I need to know how to handle keyboard events and mouse events with the GRX GPC interface. Thanks in advance for any help Markus -- http://www.gerwinski.de/~markus/

1 0

IRIX problem
by Miklos Cserzo 11 May '01

11 May '01

Hi Folks, I decided to rebuild the GPC under IRIX 6.5 from the gpc-20010502 source on the top of gcc-core-2.95.2. It is not working. Here goes the tail of the log of the make: ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 -DRTS_RELEASE_STRING="'`cat /usr/local/src/gpc/gcc-2.95.2/gcc/p/rts/rts-version`'" --unit-path=/usr/local/src/gpc/gcc-2.95.2/gcc/p/rts --automake /usr/local/src/gpc/gcc-2.95.2/gcc/p/rts/string.pas /usr/local/src/gpc/gcc-2.95.2/gcc/p/rts/string.pas: In function `Memcompcase': /usr/local/src/gpc/gcc-2.95.2/gcc/p/rts/string.pas:207: Internal compiler error in `add_bound_info', at gcc-2.95.2/gcc/dwarf2out.c:7376 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gmake[2]: *** [string.o] Error 1 gmake[2]: Leaving directory `/usr/local/src/gpc/build/gcc/p/rts' gmake[1]: *** [pascal.rts] Error 2 gmake[1]: Leaving directory `/usr/local/src/gpc/build/gcc' gmake: *** [all-gcc] Error 2 In the configure only the the --enable-languages=pascal switch was used. Then a plain gmake without any extra bells or whistles. What went wrong? Cheers, miklos Miklos Cserzo University of Birmingham c/o School of Biosciences MRC - Bioinformatics Project Tel: +44-121-414-3037 Schools of Biosciences and Medicine Fax: +44-121-414-5925 Edgbaston, Birmingham B15 2TT E-mail: miklos(a)bip.bham.ac.uk United Kingdom

3 4

Re: Problem with unpacking of gpc-20010423_tar.gz
by Maurice Lombardi 11 May '01

11 May '01

Kocherlakota Harikrishna wrote: > Hello, > It's source form only. Not from binary. > It's from : > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-20010423.tar.gz But even a source file, when compressed by gzip, becomes a binary file which must be downloaded in binary mode. -- 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

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 May 2001