Gpc

gpc@gnu.de

5400 discussions

Newbie question ...
by da Silva, Joe 22 May '01

22 May '01

Greetings. I hope I haven't missed the answer to this question somewhere (I have looked at the online information, but couldn't find it ...) : Is there a stub/extender available, for the DJGPP build of the compiler, that provides DPMI services for an application, instead of loading CWSDPMI? I tried stubbing the "Hello world" example using WDOSX, but this simply crashed the computer ... Regards, Joe.

1 0

reset() regression
by Ian Thurlbeck 21 May '01

21 May '01

Hello all I've just noticed a small difference with the gpc-20010512 compiler from the one I was using (gpc-19991030). If you do: program restest(input,output); var s:string(40); t:text; begin s:=""; {$i-} reset(t,s); if (IOResult = 0) then writeln('File exists') else writeln('File does not exist'); end. the 1999 compiled code produces "File does not exist" whilst the 2001 code produces "File exists". Not sure if you consider this worth fixing given I can test for "" before I do the reset() easily enough. ( A "" filename is produced by some legacy code I maintain, when someone presses RETURN to a filename: prompt. Not very sensible to go passing it to reset(), but there you go. ) Yours Ian -- Ian Thurlbeck http://www.stams.strath.ac.uk/ Statistics and Modelling Science, University of Strathclyde Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079

2 1

Re: Compiling latest gpc on latest cygwin (fwd)
by Matthias Braun 16 May '01

16 May '01

Forgot the attachements :) I don't attach gpcpp.c (cause it's 360k) I'll send it to anyone asking. On Wed, 16 May 2001, Prof. A Olowofoyeku (The African Chief) wrote: > On 15 May 2001, at 16:39, Matthias Braun wrote: > > > 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. > > I am not sure that you should do that. I think you should trust that > whoever undeclared it knew what they were doing. I normally can compile > GPC for both Cygwin and Mingw without touching anything other than to > apply the GPC patch. So I looked into the cccp.c file which seems to be the c counterpart to gpcpp.c, here they did a #ifdef TOOL_INCLUDE_DIR around the critical parts, so I did the same for gpcpp.c and restored original cygwin.h. But this gives the same effect as before. > > After that compiling worked, but if I use the compile now, the following > > appears: (gpc -v test.pas) > > Do you have all the latest GNU tools and headers and libraries? You > shouldn't have had to change cygwin.h to be able to build GPC > successfully. Yes, I used the setup utility from cygwin.com and installed experimental releases (gcc package isn't marked experimental anyway). I installed all the tools there. > [...] > > 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 > > I have never seen this problem before. The GPC that you built is > obviously broken. Why? I have no idea. Could it be a problem with your > "specs" file? Perhaps Peter or Frank might have an idea what this error > means. I reinstalled everything, I did some tests, compiling works if I use the following sequence: gpc -c -o test.o test.pas gcc test.o -o test.exe -lgpc So It seems only an error reading the specs file, but I don't understand the spec file syntax :/. So I've attached it along with the changed gpcpp.c to this mail. Matze

3 2

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

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