September 2007 - Gpc

Inefficiency of `mod'
by Emil Jerabek 25 Oct '10

25 Oct '10

Hi, during some debugging I noticed that GPC generates very hairy code for the `mod' operator with signed arguments. A closer look revealed that the code contains a lot of branching on conditions which can be determined on compile time, and most surprisingly, the value of X mod Y is recomputed _twice_, if X is negative. (I've attached a commented assembler dump.) This may be partially a back-end problem (CSE?), but I feel there's something wrong in the relevant code in gpc-common.c (build_pascal_binary_op) as well. `exp1 mod exp2' gets translated into something like exp2 <= 0 ? error : exp1 >= 0 ? exp1 mod exp2 : ((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2 This arranges that both arguments supplied to the "internal mod" are non-negative, but this information is not passed on -- the arguments are still declared as signed types, which apparently makes the back-end to produce the mess it does. I've done a little test: the following replacement for `mod', which differs from the built-in one essentially just by the type-casts to `Cardinal', inline operator xmod (X, Y: Integer) = Z: Integer; begin if Y <= 0 then RuntimeError (714); if X >= 0 then Z := Cardinal (X) mod Y else begin Z := Cardinal (-X) mod Y; if Z <> 0 then Z := Y - Z end end; indeed generates a better code, it measures about 15% faster for positive X and more than twice faster for negative X. YMMV. If this is possible in user code, it should work in the compiler internals as well :) The result type of the whole `mod' expression looks dubious too. IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result of `mod' is guaranteed to be nonnegative and to fit in the type of exp2 (or more precisely, it is in 0 .. High (type of (exp2)) - 1), whereas it needn't have anything to do with the type of exp1: consider var X, Z: Integer; Y: LongInt; begin X := -8; Y := High (LongInt); Z := X mod Y { -> overflow } end Or am I missing something? Emil (BTW, where is fjf434c.pas?)

10 16

New (gpc-20060325)
by Waldek Hebisch 08 Dec '09

08 Dec '09

I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2 Main change is preliminary gcc-4.0.x support. The other changes are rather small. Note that for "production use" 3.4.x and 3.3.x backend are prefered. Also, using 2.8.1, 2.95.3 and 3.2.3 backend should work, but is depreciated. For more detail see: http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20060325 and http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20060325 -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

7 44

compiling static library + gpc runtime without _statvfs on Mac OS X for Intel
by Glenn Howes 20 Apr '08

20 Apr '08

Hello, After months of being distracted by another portion of my application, I'm back to creating a universal binary version of the Pascal based library we are linking into our C++ based application. The problem is the application will not launch under PPC on Mac OS X 10.3 (Panther). The console registers an undefined symbol: _statvfs expected to be defined in /usr/lib/libSystem.B.dylib After some research, I found this call is being used by the StatFS routine implemented in rts.c (line 1510) /** Get information about a file system. */ GLOBAL (Boolean _p_StatFS (char *Path UNUSED, StatFSBuffer *Buf)) { int Result; #ifdef HAVE_STATVFS struct statvfs b; errno = 0; Result = statvfs (Path, &b); Buf->BlockSize = (long long int) b.f_frsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_favail; #elif defined (HAVE_STATFS) struct statfs b; errno = 0; Result = statfs (Path, &b); Buf->BlockSize = (long long int) b.f_bsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_ffree; #else Result = -1; errno = ENOSYS; #endif if (Result == 0) return True; Buf->BlockSize = 0; Buf->BlocksTotal = 0; Buf->BlocksFree = 0; Buf->FilesTotal = 0; Buf->FilesFree = 0; return False; } It appears to me that HAVE_STATVFS is defined if my current OS X SDK (10.4) has a statvfs.h header file amongst its include files, which means if I build my Pascal development environment from the build-on- Intel.command that the statvfs version will be hard wired into the runtime and any binary I generate will not work on 10.3 (which does not have statvfs in its libSystem.B.dylib library). Also, if I build my environment/library on a PowerPC using the build-on- powerPC-10.3.command, I end up with a different set of link problems involving the long double version of pow(). Besides which, I'd prefer to do my development on OS X for Intel going forward. I have tried hand editing the above routine and rebuilding my Pascal development environment, and pulling the statvfs.h file from my OS X SDK, and yet when my application links, it still has an unresolved reference to _statvfs. I'm not a build engineer, as my previous missives to this mailing list make clear, and I'm at a loss as to how to proceed. Just to be clear, I link in two static libraries: a universal version of the libgpc.a for the runtime, and a universal version of the library I've created. Neither of them contain the symbol _statvfs (at least I can't find that text in them). I link that with my application. The application now references _statvfs (I can now see the text in it's executable). I can't launch on 10.3. I comment out the calls to the Pascal library and recompile+relink, and the application no longer has the symbol and I can launch under 10.3. So something in either of the gpc associated libraries must be calling something which calls statvfs, making the linker (ld) mark statvfs as an unresolved symbol to be loaded in at runtime. At least that is my impression. So, I'd appreciate some suggestions. --glenn

4 8

Memory layout of array of variable size.
by Bastiaan Veelo 24 Dec '07

24 Dec '07

Hi, In an attempt to hook up to GTK+, I am trying to pass a Pascal array of varible size to C. Static arrays are fine, but these arrays carry some additional information like capacity and size, and I gues they could be received as a struct on the C-side. However, I cannot figure out the structure that the struc should have. I do like this in Pascal: procedure YGTK_init(var argc : CInteger; argv : array of CString); external name 'YGTK_init'; procedure Y_init; var argc : CInteger; argv : array[0..ParamCount] of CString; Counter : integer; begin argc := ParamCount+1; for Counter := 0 to ParamCount do begin argv[Counter] := NewCString(ParamStr(Counter)); end; YGTK_init(argc, argv); end; And like this in C: struct t_argv { int end; void *argv; }; void YGTK_init( int *argc, struct t_argv argv ) { printf("In ygtk.c:YGTK_init.\n"); printf("argv.end: %d\n", argv2.argc); printf("argv.argv address: %p\n", argv2.argv); printf("argv.argv int: %d\n", argv2.argv); printf("argv.argv string: %s\n", argv2.argv); printf("number of arguments: %d\n", *argc); } So I figured out that the first element in the struct is an integer containing the length-1 of the array, but what it should look like for the rest I do not know yet. Do you have an idea? Thanks, Bastiaan.

5 9

gpc issue with some record structure
by Peter Schorn 02 Oct '07

02 Oct '07

I did some further investigations on the gpc issue I recently discovered on Mac OS X 10.4.10 PowerPC (gpc 20070904, based on gcc-4.1.2). The following program exhibits the problem: program schorn3; type abc = record a, b, c: Extended; end; const d = 22092007.192016; procedure outer; var x: abc; procedure inner(p: abc); begin if x.a = d then writeln('OK') else writeln('Fail. Got x.a = ', x.a, '. Expected x.a =', d); end; begin { outer } x.a := d; inner(x); end; begin outer; end. The following behavior is observed: peter% /Developer/Pascal/gpc412/bin/gpc -o schorn3 schorn3.pas peter% schorn3 Fail. Got x.a = -3.066700750256657e-231. Expected x.a = 2.209200719201600e+07 Now with --pack-struct (although it seems there is nothing to pack) peter% /Developer/Pascal/gpc412/bin/gpc --pack-struct -o schorn3 schorn3.pas peter% schorn3 OK The previous test program for this issue caused bus errors or segmentation faults on Macintoshes but also had a chance to succeed by chance (only a boolean at a possibly wrong address was tested). Maybe the issue now shows up on other platforms as well. Peter ----- peter.schorn at acm.org

5 7

Re: [RFC-3] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

> -----Original Message----- > From: Joel Brobecker [mailto:brobecker@adacore.com] > Sent: Thursday, September 27, 2007 6:32 PM > To: Pierre Muller; 'Adriaan van Os'; gpc(a)gnu.de; gdb- > patches(a)sourceware.org > Subject: Re: [RFC-3] Handle GPC specific name for main function > > > > > Anyhow, this can only lead to failures to detect > > > > GPC properly. I think that the patch, even if it might > > > > miss more cases, is also much more safe this way, because > > > > we only use (_p_MO__main_program or pascal_main_program) > > > > as start command breakpoint if '_p_initialize' was also found. > > > > > > Seems reasonable to me. Joel? > > > > Seems reasonable to me too. > > Actually, is it really reducing the potential for false positives? > > Let's recap: _p_initialize is defined when the Pascal runtime is linked > in. _p_MO__main_program is sufficiently unlikely that such a symbol > name > should be a Pascal procedure pretty much all the time. So I'm wondering > whether checking for _p_initialize will help reducing the number of > false positive at all (because would _p_MO__main_program => > _p_initialize). > So is this patch really better than the previous one? Yes, because it was not simply '_p__M0_main_program' but basically: if msym('_p_M0_main_program') exists, return '_p__M0_main_program' else if sym('pascal_main_program') exist, return 'pascal_main_program' else return NIL. The old name is more usual, and could be generated by any compiler (its even a valid C function name, if if there is not underscore prepended!). To avoid false positives on the second version mainly, it is better. We could decide to do the check of '_p_initialize' only for that second case; that would probably reduce the number of recent GPC compilation misses. Pierre Muller

1 0

[RFC-3] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

Based on comments from Waldek and concerns from Joel, I propose that we first check for the presence of the '_p_initialize' minimal symbol, and only look for '_p_M0_main_program' and 'pascal_main_program' if the '_p_initialize' was found. This should reduce substantially the risks of false catches. Joel, does this seem enough for you, or should we really insist on checking if the program was compiled by gcc, like Waldek also suggested, but which would mean that only programs having debug information present would get a chance of being detected correctly, while the present patch also works for programs without debugging information. Pierre Muller ChangeLog entry: 2007-09-27 Pierre Muller <muller(a)ics.u-strasbg.fr> * p-lang.h (pascal_main_name): New function. p-lang.c (GPC_P_INITIALIZE, GPC_MAIN_PROGRAM_NAME_1), (GPC_MAIN_PROGRAM_NAME_2): New char array constants corresponding to the three minimal symbols used by GPC compiler. (pascal_main_name): Try to find minimal symbol corresponding to the entry of GPC compiled programs. symtab.c: New include p-lang.h. (find_main_name): Try to find pascal specific main name by calling pascal_main_name. * Makefile.in (symtab.o): Add dependency on p-lang header. $ cvs diff -up p-lang.h p-lang.c symtab.c Makefile.in Index: p-lang.h =================================================================== RCS file: /cvs/src/src/gdb/p-lang.h,v retrieving revision 1.12 diff -u -p -r1.12 p-lang.h --- p-lang.h 23 Aug 2007 18:08:36 -0000 1.12 +++ p-lang.h 27 Sep 2007 07:20:00 -0000 @@ -21,6 +21,9 @@ struct value; +/* Defined in p-lang.c */ +extern char *pascal_main_name (void); + extern int pascal_parse (void); /* Defined in p-exp.y */ extern void pascal_error (char *); /* Defined in p-exp.y */ Index: p-lang.c =================================================================== RCS file: /cvs/src/src/gdb/p-lang.c,v retrieving revision 1.33 diff -u -p -r1.33 p-lang.c --- p-lang.c 23 Sep 2007 16:25:05 -0000 1.33 +++ p-lang.c 27 Sep 2007 07:20:00 -0000 @@ -35,6 +35,63 @@ extern void _initialize_pascal_language (void); +/* All GPC versions until now (2007-09-27) also define a symbol called + '_p_initialize'. Check for the presence of this symbol first. */ + static const char GPC_P_INITIALIZE[] + = "_p_initialize"; + +/* The name of the symbol that GPC uses as the name of the main + procedure (since version 20050212). */ +static const char GPC_MAIN_PROGRAM_NAME_1[] + = "_p__M0_main_program"; + +/* Older versions of GPC (versions older than 20050212) were using + a different name for the main procedure. */ +static const char GPC_MAIN_PROGRAM_NAME_2[] + = "pascal_main_program"; + +/* Function returning the special symbol name used + by GPC for the main procedure in the main program + if it is found in minimal symbol list. + This function tries to find minimal symbols generated by GPC + so that it finds the even if the program was compiled + without debugging information. + According to information supplied by Waldeck Hebisch, + this should work for all versions posterior to June 2000. */ + +char * +pascal_main_name (void) +{ + struct minimal_symbol *msym; + + msym = lookup_minimal_symbol (GPC_P_INITIALIZE, NULL, NULL); + + /* If '_p_initialize' was not found, + the program doesn't seem to be compiled with GPC. + Thus default name "main" should work. */ + if (msym == NULL) + return NULL; + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_1, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_1; + } + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_2, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_2; + } + +/* No known entry procedure found, use default 'main' name. + According to Waldek Hebish, this should not happen for any GPC version + after June 2000 and up to 2007-09-27. */ + return NULL; +} + /* Determines if type TYPE is a pascal string type. Returns 1 if the type is a known pascal type This function is used by p-valprint.c code to allow better string display. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.165 diff -u -p -r1.165 symtab.c --- symtab.c 24 Sep 2007 07:40:32 -0000 1.165 +++ symtab.c 27 Sep 2007 07:20:01 -0000 @@ -40,6 +40,7 @@ #include "filenames.h" /* for FILENAME_CMP */ #include "objc-lang.h" #include "ada-lang.h" +#include "p-lang.h" #include "hashtab.h" @@ -4151,6 +4152,13 @@ find_main_name (void) return; } + new_main_name = pascal_main_name (); + if (new_main_name != NULL) + { + set_main_name (new_main_name); + return; + } + /* The languages above didn't identify the name of the main procedure. Fallback to "main". */ set_main_name ("main"); Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.938 diff -u -p -r1.938 Makefile.in --- Makefile.in 17 Sep 2007 19:32:53 -0000 1.938 +++ Makefile.in 27 Sep 2007 07:20:02 -0000 @@ -2751,7 +2751,7 @@ symtab.o: symtab.c $(defs_h) $(symtab_h) $(filenames_h) $(objc_lang_h) $(ada_lang_h) $(hashtab_h) \ $(gdb_obstack_h) $(block_h) $(dictionary_h) $(gdb_string_h) \ $(gdb_stat_h) $(cp_abi_h) $(observer_h) $(gdb_assert_h) \ - $(solist_h) $(ada_lang_h) + $(solist_h) $(p_lang_h) target.o: target.c $(defs_h) $(gdb_string_h) $(target_h) $(gdbcmd_h) \ $(symtab_h) $(inferior_h) $(bfd_h) $(symfile_h) $(objfiles_h) \ $(gdb_wait_h) $(dcache_h) $(regcache_h) $(gdb_assert_h) $(gdbcore_h) \

3 5

Re: [RFC-3] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

> -----Original Message----- > From: gdb-patches-owner(a)sourceware.org [mailto:gdb-patches- > owner(a)sourceware.org] On Behalf Of Daniel Jacobowitz > Sent: Thursday, September 27, 2007 2:11 PM > To: Pierre Muller > Cc: 'Adriaan van Os'; gpc(a)gnu.de; gdb-patches(a)sourceware.org > Subject: Re: [RFC-3] Handle GPC specific name for main function > > On Thu, Sep 27, 2007 at 09:57:41AM +0200, Pierre Muller wrote: > > > On second thought - are these symbols present when linking to a > dynamic > > > libgpc ? > > > > Does this matter anyhow? > > We are just trying to get the > > gdb command 'start' to end up at the right location, > > i.e. for a pascal program, at the start of > > the main procedure of the main source. > > Yes, it matters. libgpc will not be loaded yet, so _p_initialize > might be missing when we try to find the main function. Would then looking after __imp_p_initialize find something? You need to excuse me, but I have no idea of the library loading works... Anyhow, this can only lead to failures to detect GPC properly. I think that the patch, even if it might miss more cases, is also much more safe this way, because we only use (_p_MO__main_program or pascal_main_program) as start command breakpoint if '_p_initialize' was also found. Pierre

1 0

[RFC] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

This patch looks up for GPC specific minimal symbols and assumes that if they are present, the executable was compiled by GPC. GPC used 'pascal_main_program' and now uses '_p__M0_main_program'. Is there some other way to check that the program was really compiled by GPC? (Any C compiled program could have a 'pascal_main_program' function...) Maybe by looking up some other symbol? I found 'GPC_init' as a possible candidate, but I am not sure that this symbol is defined for all versions of GPC, so I did not include it in the present RFC. I tested the patch on Cygwin and it allows to use 'start' command and get directly at the right location. This will also help to reduce the gap between GPC and FreePascal for the (not yet committed) gdb.pascal testsuite directory. Any feedback from GPC users would be most helpful here. Pierre Muller Pascal language maintainer. ChangeLog entry: 2007-09-26 Pierre Muller <muller(a)ics.u-strasbg.fr> * p-lang.h (pascal_main_name): New function. p-lang.c (GPC_MAIN_PROGRAM_NAME_1, GPC_MAIN_PROGRAM_NAME_2): New char array constants corresponding to the two minimal symbols used by GPC compiler. (pascal_main_name): Try to find minimal symbol corresponding to the entry of GPC compiled programs. symtab.c (find_main_name): Try to find pascal specific main name by calling pascal_main_name. $ cvs diff -up p-lang.h p-lang.c symtab.c Index: p-lang.h =================================================================== RCS file: /cvs/src/src/gdb/p-lang.h,v retrieving revision 1.12 diff -u -p -r1.12 p-lang.h --- p-lang.h 23 Aug 2007 18:08:36 -0000 1.12 +++ p-lang.h 26 Sep 2007 14:26:08 -0000 @@ -21,6 +21,8 @@ struct value; +extern char *pascal_main_name (void); + extern int pascal_parse (void); /* Defined in p-exp.y */ $ Index: p-lang.c =================================================================== RCS file: /cvs/src/src/gdb/p-lang.c,v retrieving revision 1.33 diff -u -p -r1.33 p-lang.c --- p-lang.c 23 Sep 2007 16:25:05 -0000 1.33 +++ p-lang.c 26 Sep 2007 14:26:09 -0000 @@ -35,6 +35,43 @@ extern void _initialize_pascal_language (void); +/* The name of the symbol used by GPC compiler. */ + +static const char GPC_MAIN_PROGRAM_NAME_1[] + = "pascal_main_program"; +static const char GPC_MAIN_PROGRAM_NAME_2[] + = "_p__M0_main_program"; + +char * +pascal_main_name (void) +{ + struct minimal_symbol *msym; + CORE_ADDR main_program_name_addr; + static char main_program_name[1024]; + + /* For GPC, main procedure s a special name. + . */ + + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_1, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_1; + } + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_2, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_2; + } + + /* The main procedure doesn't seem to be in GPC. + Thus default "main" should work. */ + return NULL; +} + /* Determines if type TYPE is a pascal string type. Returns 1 if the type is a known pascal type This function is used by p-valprint.c code to allow better string display. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.165 diff -u -p -r1.165 symtab.c --- symtab.c 24 Sep 2007 07:40:32 -0000 1.165 +++ symtab.c 26 Sep 2007 14:26:10 -0000 @@ -40,6 +40,7 @@ #include "filenames.h" /* for FILENAME_CMP */ #include "objc-lang.h" #include "ada-lang.h" +#include "p-lang.h" #include "hashtab.h" @@ -4151,6 +4152,13 @@ find_main_name (void) return; } + new_main_name = pascal_main_name (); + if (new_main_name != NULL) + { + set_main_name (new_main_name); + return; + } + /* The languages above didn't identify the name of the main procedure. Fallback to "main". */ set_main_name ("main");

2 1

Re: [RFC] Handle GPC specific name for main function
by Pierre Muller 26 Sep '07

26 Sep '07

> I am mostly concerned about the effect on the other languages. > I just want to make sure that the rest of the testsuite results > stay unchanged. If you don't have access to a machine where you > can run the testsuite, then let me know, and I'll give it a quick > run on one of our fast machines for you. Your change looks relatively > straightforward, but it never hurts to be cautious. > I finally ran the testsuite on Ubuntu (inside VMWare) The outcome is a bit better after the patch, but I do NOT understand how this patch could have any influence on 'help' behavior. Thus I suspect that this is just non-reproducable... Pierre gdb.sum.before is for a clean CVS, gdb.sum is after applying the patch. fpc@ubuntu:/usr/local/src/build/gdb/testsuite$ diff gdb.sum.before gdb.sum 1c1 < Test Run By fpc on Wed Sep 26 22:41:20 2007 --- > Test Run By fpc on Wed Sep 26 23:37:23 2007 3056,3060c3056,3060 < FAIL: gdb.base/help.exp: help clear (timeout) < FAIL: gdb.base/help.exp: help commands < FAIL: gdb.base/help.exp: help condition < FAIL: gdb.base/help.exp: help core-file < FAIL: gdb.base/help.exp: help delete "d" abbreviation --- > PASS: gdb.base/help.exp: help clear > PASS: gdb.base/help.exp: help commands > PASS: gdb.base/help.exp: help condition > PASS: gdb.base/help.exp: help core-file > PASS: gdb.base/help.exp: help delete "d" abbreviation 11129,11130c11129,11130 < # of expected passes 10489 < # of unexpected failures 38 --- > # of expected passes 10494 > # of unexpected failures 33

1 1