Gpc April 2006

gpc@gnu.de

18 participants
29 discussions

An other gdb useful patch
by Pascal Viandier 05 Apr '06

05 Apr '06

When debugging gpc programs, I often get a gdb coredump when printing the value of string which is not -yet- initialized. This happens even more often when using ddd on top of gdb since the value is displayed as soon as you move the mouse pointer over the variable name. This problem occurs because gdb uses the value of the 'length' field of the string type schema to print the string contents. If the string is not initialized, this field may contain any value -even negative- so it crashes gdb. I solved this bug (IMHO this is one) by getting the Capacity field too. This field is always initialized for gpc strings - this is an assumption -. When printing a string, I compare the value of the actual length and the value of the capacity of the string. If the length is either negative or greater than the capacity, the capacity is used to print out the value. This modification has no impact on other Pascal string types (BP, etc). I put the patches (4) for gdb 6.4 in attachment. If someone estimates these patches are interesting enough to transmit them to the gdb maintainers, feel free to do so. I am not a member of the gdb mailing list and I do not know how to submit patches to them. Hope this will help someone. Kind regards Pascal

3 9

Integer Of
by Contestcen＠aol.com 05 Apr '06

05 Apr '06

<< I feel we should use consistent terminology. The SizeOf function returns a number of bytes, the BitSizeOf function returns a number of bits. Using just "size" when the requested parameter is a number of bits, introduces sloppy terminology, which - in general - is a source of programming errors. With IntegerOf(n), one can (implicitely) read IntegerOf(bits), so I think that is OK. Regards, Adriaan van Os >> If you want to be grammatical and consistent, then consider IntegerOfBitSize(n). For my taste, however, this is just too long. Frank Rubin

1 0

(no subject)
by Contestcen＠aol.com 04 Apr '06

04 Apr '06

In a message dated 4/2/2006 10:51:12 AM Eastern Standard Time, ih8mj(a)fjf.gnu.de writes: << BTW, native speakers, with formulation is better, "integer with/of N bits"? >> The description "Integer of N bits" is better. For the declaration, both IntegerOfBits(n) and IntegerWithBits(n) seem awkward. I would prefer the shorter IntegerOf (n) or possibly IntegerOfSize (n). Frank Rubin

3 2

gdb 6.4 patch
by Pascal Viandier 03 Apr '06

03 Apr '06

I installed gdb 6.4 on my Debian x86 box and made the patch for gpc in it. To who may be interested, here it is :-) --- gdb-6.4/gdb/dwarf2read.c 2005-11-03 21:58:31.000000000 -0500 +++ gdb-6.4.new/gdb/dwarf2read.c 2006-03-31 14:15:52.000000000 -0500 @@ -911,6 +911,8 @@ static void read_enumeration_type (struct die_info *, struct dwarf2_cu *); +static void read_set_type (struct die_info *, struct dwarf2_cu *); + static void process_enumeration_scope (struct die_info *, struct dwarf2_cu *); static struct type *dwarf_base_type (int, int, struct dwarf2_cu *); @@ -2648,6 +2650,9 @@ read_enumeration_type (die, cu); process_enumeration_scope (die, cu); break; + case DW_TAG_set_type: + read_set_type (die, cu); + break; /* FIXME drow/2004-03-14: These initialize die->type, but do not create a symbol or process any children. Therefore it doesn't do anything @@ -4031,6 +4036,24 @@ return new_prefix; } +static void +read_set_type (struct die_info * die, struct dwarf2_cu *cu) +{ + struct type *domain_type; + + /* Return if we've already decoded this type. */ + if (die->type) + { + return; + } + + domain_type = die_type (die, cu); + + die->type = create_set_type (NULL, domain_type); + +} + + /* Given a pointer to a die which begins an enumeration, process all the dies that define the members of the enumeration, and create the symbol for the enumeration type. @@ -6113,9 +6136,11 @@ case DW_LANG_Ada95: cu->language = language_ada; break; + case DW_LANG_Pascal83: + cu->language = language_pascal; + break; case DW_LANG_Cobol74: case DW_LANG_Cobol85: - case DW_LANG_Pascal83: case DW_LANG_Modula2: default: cu->language = language_minimal; @@ -6904,6 +6929,7 @@ case DW_TAG_structure_type: case DW_TAG_union_type: case DW_TAG_enumeration_type: + case DW_TAG_set_type: SYMBOL_CLASS (sym) = LOC_TYPEDEF; SYMBOL_DOMAIN (sym) = STRUCT_DOMAIN; @@ -7225,6 +7251,9 @@ case DW_TAG_enumeration_type: read_enumeration_type (die, cu); break; + case DW_TAG_set_type: + read_set_type (die, cu); + break; case DW_TAG_subprogram: case DW_TAG_subroutine_type: read_subroutine_type (die, cu); @@ -7282,7 +7311,8 @@ struct die_info *parent; if (cu->language != language_cplus - && cu->language != language_java) + && cu->language != language_java + && cu->language != language_pascal) return NULL; parent = die->parent;

1 0

Re: Redeclarations of predefined ordinal
by willett 03 Apr '06

03 Apr '06

On 2 Apr 2006, at 10:46, Frank Heckenbach wrote: >> 1. Predefine 2 pseudo-schema types to define signed and unsigned >> integral types: >> >> IntegerWithBits (n) >> CardinalWIthBits (n) >> >> where n is a compile-time constant expression. >> > > BTW, native speakers, with formulation is better, "integer with/of N > bits"? > By my intuition (native speakers vary), clearest would be "Integer of N Bits". Given that the parameter cannot appear in the middle of the predefined identifier, perhaps "IntegerOfBitsize(n)". Others, including (my second choice) "IntegerOfBits(n)" are to me less clear--it suggests that other integers are not made up of bits. Ålso, "of" is more consistent with Pascal use in declarations, "with" has different Pascal semantics. IMHO Willett Kempton

1 0

Re: New (gpc-20060325)
by Adriaan van Os 03 Apr '06

03 Apr '06

>> Waldek Hebisch wrote: >> >>> Adriaan van Os wrote: >>>> Waldek Hebisch wrote: >>>>> BTW: if the same happens with standalone program (without >>>>> modules) >>>>> I should be able to reproduce it. >>>> >>>> Sorry, not clear to me what you mean. >>> >>> I have build a cross-compiler targetting Mac OSX. However, I do not >>> have the complete toolchain (only bare compiler). Without full >>> toolchain I can not compile RTS (the problem really is >>> configure) and >>> also I can not compile anything using GPC module. >>> >>> If you have a testcase which does not use GPC module (directy or >>> indirectly) I should be able to compile it. In fact, if a >>> program uses >>> no extra modules (units) at all debugging becomes easier. >>> >>> I have tried the cross-compiler on various test programs and ATM it >>> happily produced stabs debug info. >> >> OK, I understand, I will look for a testcase (or try to isolate the >> problem). > > Some observations: > > 1. the problem does not occur when running gpc directly rather than > with make, even when passing the same compiler switches (this > sounds like random behaviour and makes me think there is an > uninitialized variable somewhere in the compiler source code) > > 2. the problems disappears when I remove Turbo3 from the USES > clause in aturbo3test.pas > > 3. the problem persists when I reduce the Turbo3 unit to nothing but > > import > > System (MemAvail => System_MemAvail, > MaxAvail => System_MaxAvail); > > Will try to further narrow this down in units/System.pas. The problem disappears when I change type PMemList = ^PMemList; to type PMemList = ^Pointer; in the function MemAvail in units/system.pas. I think that explains it. Apparently the stabs symbol generator doesn't like the type PMemList = ^PMemList declaration. Regards, Adriaan van Os

3 3

Redeclarations of predefined ordinal data types
by Adriaan van Os 02 Apr '06

02 Apr '06

The following two programs are rejected by gpc program redeclare1; type Int16 = Integer attribute( size = 16); Integer = Int16; {error: identifier `Integer' redeclared in a scope where an outer value was used} begin end. program redeclare2; type Integer = Integer attribute( size = 16); {error: identifier `Integer' redeclared in a scope where an outer value was used} begin end. The following program is accepted: program redeclare3; type Integer = ShortInt; begin writeln( 'SizeOf( Integer) = ', SizeOf( Integer)) end. GPC has been accepting the above first two programs. Gale Paper reminded me that this was (probably) changed in gpc-20050325 with bug fix 20050325: check identifier scopes stricter (az25.pas, fjf1059*.pas). However, I would argue that a type definition like int_nn = Integer attribute( size = nn); does not "use" the Integer type as such in a strict sense. Thus, it can be treated as a special case, accepting the above two programs again. Same for the other predefined ordinal types that accept attribute( size = nn), like Word, Cardinal and Boolean. Regards, Adriaan van Os

4 10

Preprocessor conditional expression support bug
by Gale Paeper 02 Apr '06

02 Apr '06

While working on a MacPascal dialect to GPC porting project, I was surprised to encounter preprocessor errors in conditional compilation directives where the conditional expression directly or indirectly (i.e., a macro expansion) contained $ hex constants. A short example (thanks Afriaan): program dollars; {$definec dollars $1} {$ifc dollars = 1} {$endc} begin end. Compiling yields the error: dollars.pas:3: conditional expression: parse error If one changes {$definec dollars $1} to {$definec dollars 1}, it compiles with no problem. After some futher testing and digging into the gpcpp.c source code, it looks like the preprocessor doesn't support $ hex constants in conditional expressions for conditional compilation directives. Since $ hex constant usage in preprocessor expressions (including conditional compilation directives) has been supported in MacPascal dialect compilers for well over two decades and it has been a long standing "standard" to use hex nibble formatting convensions for things such as conditional compilation version testing, the lack of GPC preprocessor support for $ hex constants in preprocessor conditional expressions creates MacPascal to GPC code porting problems. (Note: I'm not sure how much further back $ hex constant usage in preprocessor expression has been supported in Apple's USCD Pascal derived compilers. The support was in the first MPW Pascal compiler and may have been supported in the predecessor Lisa Pascal and Apple II compilers but I don't have anything (e.g., documentation) to verify it in the predecessors.) If for no other reason than to facilitate porting of MacPascal dialect codee to GPC, the preprocessor conditional expression support needs to be fixed to allow usage of $ hex constants. Compiler used was Adriaan's pre-built GPC Mac OS X version with specs: Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 Thread model: posix gpc version 20051116, based on gcc-3.4.5 Gale Paeper gpaeper(a)empirenet.com

3 3

Re: New (gpc-20060325)
by Adriaan van Os 01 Apr '06

01 Apr '06

> Waldek Hebisch wrote: > >> Adriaan van Os wrote: >>> Waldek Hebisch wrote: >>>> BTW: if the same happens with standalone program (without modules) >>>> I should be able to reproduce it. >>> >>> Sorry, not clear to me what you mean. >> >> I have build a cross-compiler targetting Mac OSX. However, I do not >> have the complete toolchain (only bare compiler). Without full >> toolchain I can not compile RTS (the problem really is configure) >> and >> also I can not compile anything using GPC module. >> >> If you have a testcase which does not use GPC module (directy or >> indirectly) I should be able to compile it. In fact, if a program >> uses >> no extra modules (units) at all debugging becomes easier. >> >> I have tried the cross-compiler on various test programs and ATM it >> happily produced stabs debug info. > > OK, I understand, I will look for a testcase (or try to isolate the > problem). Some observations: 1. the problem does not occur when running gpc directly rather than with make, even when passing the same compiler switches (this sounds like random behaviour and makes me think there is an uninitialized variable somewhere in the compiler source code) 2. the problems disappears when I remove Turbo3 from the USES clause in aturbo3test.pas 3. the problem persists when I reduce the Turbo3 unit to nothing but import System (MemAvail => System_MemAvail, MaxAvail => System_MaxAvail); Will try to further narrow this down in units/System.pas. Regards, Adriaan van Os

3 5

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 April 2006