Waldek Hebisch wrote:

This in a known problem with gdb -- all released gdb versions have problem with Pascal DWARF-2 debug info. You can try `-gstabs+' to choose stabs debug format. Or you may try patching gdb to get better Pascal DWARF-2 support:

http://www.math.uni.wroc.pl/~hebisch/gpc/gdb-6.3.diff

Any chance of getting these patches into the gdb tree ?

Regards,

Adriaan van Os

Waldek Hebisch wrote:

Adriaan van Os wrote:

...

Waldek Hebisch wrote:

...

This in a known problem with gdb -- all released gdb versions have problem with Pascal DWARF-2 debug info. You can try `-gstabs+' to choose stabs debug format. Or you may try patching gdb to get better Pascal DWARF-2 support:

http://www.math.uni.wroc.pl/~hebisch/gpc/gdb-6.3.diff

Any chance of getting these patches into the gdb tree ?

Things are moving now: gdb maintainers agreed to accept the patch, so now it remains to do paperwork (copyright assignment).

Good work !

Regards,

Adriaan van Os

Hi Waldek,

I applied the gdb-6.3.diff to the gdb 6.3 and now the segmentation fault stack is showed correctly. The problem is related to a rewrite operation under trap handler, it seems that the _p_Rewrite procedure received a wrong pointer to file variable.

Pascal source code which generate the segmentation fault:

procedure tmp_opn_fnm (var p : iop_out_t; var fn: fil_spec_t; var f : text); var fs: string(fil_spec_l); tstr: TString;

procedure TrapRewriteIOErr (Trapped : Boolean); begin if Trapped then begin ioerr := true; tstr := TrappedErrorMessageString; end else begin rewrite (f,fs); end end;

begin fs := fn.body; SetLength(fs,fn.length); TrapExec(TrapRewriteIOErr); {apertura file in output} TrapReset; if (ioerr = true) then begin ios_traperr (tstr); prg_abort; end; p.trnctr := p.trnctr + [iop_opn]; end;

This source is incomplete

Segmentation Fault Stack frames:

(gdb) run Starting program: /dktlvqpe1/grfdev/ags/grfpkglnxv12/grfc.exe GRF> cc_gra_sc.smt /out= cc_gra_sc.c Program received signal SIGSEGV, Segmentation fault. 0x0807ef1a in _p_InternalOpen (f=0x0, FileName=0xbfffe238 '/dktlvqpe1/grfdev/ags/grfpkglnxv12/cc_gra_sc.111', Length=1, BufferSize=1, Mode=Fo_reset) at files.pas:1639 1639 if f^.Status.Untyped then (gdb) where #0 0x0807ef1a in _p_InternalOpen (f=0x0, FileName=0xbfffe238 '/dktlvqpe1/grfdev/ags/grfpkglnxv12/cc_gra_sc.111', Length=1, BufferSize=1, Mode=Fo_reset) at files.pas:1639 #1 0x08084fab in _p_Rewrite (f=0x0, aFileName=@0xbfffe230, FileNameGiven=true, BufferSize=1) at files.pas:3238 #2 0x0804fe9b in Traprewriteioerr.1 () at grfuxtmp.p:85 #3 0x0807311f in Docall.0 () #4 0x080732fb in dosetjmp () #5 0x080731e4 in _p__M4_Trap_S3_Trapexec () #6 0x08050024 in tmp_opn_fnm (p=@0x80a2940, fn=@0xbfffe2f0, f=@0x80a28ec) at grfuxtmp.p:94 #7 0x08051c17 in iniz () at grfcdini.p:169 #8 0x080511ce in mcm_begin () at grfcdpin.p:154 #9 0x0804b100 in main_pre (d_verb='GRF ') at grfdpmai.p:50 #10 0x0804a06c in main program () at grfidt.p:8 #11 0x0804a0e1 in main (argc=1, argv=0xbfffe494, envp=0xbfffe49c) at <implicit code>:14 (gdb)

---

it seems that _p_Rewrite function receives a wrong paramenter (0x0) as a reference to a file (f) variable. Does such variable (referenced by TrapExec nesting calls) to be defined with specific attributes?

No, it should just work. Since your source is incomplete I tried to add missing parts to it. However, my completed version works fine. Have you verified that the argument to tmp_opn_fnm is initialized? The backtrace shows non-null value, but the backtrace may be inaccurate, so it is better to print value of your variable.

Angelo Fumagalli wrote:

The file vriable and the procedure invocation are declared in other units, as:

unit grfeveis; interface const ..... var tmpf : text; tmpf2: text; sym: text; ..... end.

<Incomplete source skipped>

The problem is related to the fact that file variable tmpf isn't initialized automatically, I set a beakpoint at the beginning of the program (main_pre) and I saw that some file variables (inp, ou) declared in unother pascal unit (prenv) were properly initialized, but which (tmpf, tmpf2, sym) declared into the grfeveis unit are not initialized. In fact the gdb report is:

(gdb) break main_pre Breakpoint 1 at 0x804b0a7: file grfdpmai.p, line 44. (gdb) run Starting program: /dktlvqpe1/grfdev/ags/grfpkglnxv12/grfc.exe

Breakpoint 1, main_pre (d_verb='GRF ') at grfdpmai.p:44 44 if not(prg_host in [1,3]) then cli_setraw; (gdb) where #0 main_pre (d_verb='GRF ') at grfdpmai.p:44 #1 0x0804a06c in main program () at grfidt.p:8 #2 0x0804a0e1 in main (argc=1, argv=0xbfffb4d4, envp=0xbfffb4dc) at <implicit code>:14 (gdb) print _p__M5_Prenv_S7_Inp $1 = {_p_File_ = 0x9f83080} (gdb) print _p__M5_Prenv_S9_Ou $2 = {_p_File_ = 0x9f7f000} (gdb) print _p__M8_Grfeveis_S2_Tmpf2 $3 = {_p_File_ = 0x0} (gdb) print _p__M8_Grfeveis_S3_Tmpf $4 = {_p_File_ = 0x0} (gdb) print _p__M8_Grfeveis_S4_Sym $6 = {_p_File_ = 0x0} (gdb) __________________________________________

The question is: Why such file variables aren't initialized automatically at the program start? I need to call some internal gpc function to force the proper initialization?

Thank you very much in advance for your help.

The variable should be initialized automatically. The rules are: 1) You have to give explict import or uses clause. It does not matter if import is direct or indirect, but if you want to use something from `grfeveis' then there must be a dependency chain from main program to `grfeveis'. 2) Variables in a single module are initialized sequentially. 3) You should not depend on the order in which modules are initialized. It is not arbitrary, but may change in the future.

Typical reason for uninitialized variables are missing dependencies (uses clauses). Sources that you posted are incomplete, so I can not tell more.

Waldek Hebisch wrote:

Ernst-Ludwig Bohne wrote:

...

Simplifying your program I observe the same problem:

PROGRAM testsubrange; var i: ShortInt; {signed 16 bit integer} j: SizeType; {unsigned 32 bit word} point : record x,y: real end; {takes 16 bytes} begin i:= 3658; j:= 16; writeln ('result1 = ', i*j); {58528, OK} writeln ('result2 = ', i*SizeOf(point)); {-7008, wrong} end.

My suspicion is that for calculating the second expression the compiler uses wrong operand size (16? bit) instead of 32 (function SizeOf returns a value of SizeType). BTW: -7008+2^16 = 58528

Basically speaking gpc performs operations up to precision of more precise argument. When computing `i*j' gpc notes that `j' is more precise (usually `SizeType' has 32-bit or better precision) and uses its precision to perform multiplication. In the second case (`i*SizeOf(point)') gpc notes that `SizeOf(point)' is a constant and that this constant fits into 16-bits, and uses only 16-bit precision for multiplication.

Also, ATM gpc has no runtime overflow checking, so one silently gets incorrect result.

You may ask gpc is "correct". That is samewhat tricky question. Namely, gpc applies rules, and AFAICS it applies exactly the rules which were intended by programers coding them (I think Frank changed rules to the current ones). So the real question is if the rules are good ("correct"). Now, it would be nice to have rules which always give mathematically correct result (in other words, use precision big enough to avoid any possibility of overflow). But this is impossible in currect gpc: we have maximal precision and we can not go beyond that. Another possibility is to give correct results if possible and use maximal precision otherwise. However, the maximal precision is really a "double precision". Namely, gpc can perform arithmetic at twice of normal machine precision. Which is nice, but expensive: such operation may be significantly slower then normal operations. ATM gpc is rather dumb when predicting needed precision, so even if arguments are small gpc may think that maximal precision is needed. Also, even maximal precision may still give you wrong results.

So, there is rather nasty compromise between correctness and speed. I usuallt go for correctness. However, here speed penalty may be very significant (about 3 times when done right, but may be as high as 20 if maximal precision is slow). So, having optional overflow checking looks more attractive: one can test with overflow checking on and then release with checking off.

Yes, that's my reasoning too. I've always had overflow checking in mind (even though I also cannot work on it in the near future). And, of course, there should always be a way to force evaluation in higher precision if needed. In GPC/BP modes, type-casting one operand is a common way (also common in BP code). In ISO mode, we don't have such a way, AFAICS. OTOH, ISO doesn't support types larger than `Integer' anyway.

One could also try to invent some compromise rules, for example trying to use "most precise fast arithmetic", but doint it right is tricky.

And it makes testing for several targets tricky, because they can differ about which types are fast -- not only relating to size, but also to Pascal types, e.g. MedInt may be fast or not.

However, I do see a GPC problem here. According to ISO Pascal, operations should not be done on smaller than Integer types. GPC followed this rule for `+' and `-', but not for other operations. The attached patch fixes this. It doesn't cause any regressions in the test suite on IA32 (but I haven't tested on other systems yet, and type size changes are always somewhat critical -- that's why I included 3 versions of these test programs, even if rather similar). Whether SizeOf gives a result of type SizeType or another type is quite irrelevant as GPC mostly ignores types of integer constants.

Frank

Frank Heckenbach wrote:

...

One could also try to invent some compromise rules, for example trying to use "most precise fast arithmetic", but doint it right is tricky.

And it makes testing for several targets tricky, because they can differ about which types are fast -- not only relating to size, but also to Pascal types, e.g. MedInt may be fast or not.

However, I do see a GPC problem here. According to ISO Pascal, operations should not be done on smaller than Integer types. GPC followed this rule for `+' and `-', but not for other operations. The attached patch fixes this. It doesn't cause any regressions in the test suite on IA32 (but I haven't tested on other systems yet, and type size changes are always somewhat critical -- that's why I included 3 versions of these test programs, even if rather similar).

Thanks for the patch ! It fixes the problem and doesn't cause any regressions on powerpc-apple-darwin7.

Whether SizeOf gives a result of type SizeType or another type is quite irrelevant as GPC mostly ignores types of integer constants.

But it also ignores explicit typecasts on integer constants (see below).

...

Basically speaking gpc performs operations up to precision of more precise argument. When computing `i*j' gpc notes that `j' is more precise (usually `SizeType' has 32-bit or better precision) and uses its precision to perform multiplication. In the second case (`i*SizeOf(point)') gpc notes that `SizeOf(point)' is a constant and that this constant fits into 16-bits, and uses only 16-bit precision for multiplication.

Also, ATM gpc has no runtime overflow checking, so one silently gets incorrect result.

You may ask gpc is "correct". That is samewhat tricky question. Namely, gpc applies rules, and AFAICS it applies exactly the rules which were intended by programers coding them (I think Frank changed rules to the current ones). So the real question is if the rules are good ("correct"). Now, it would be nice to have rules which always give mathematically correct result (in other words, use precision big enough to avoid any possibility of overflow). But this is impossible in currect gpc: we have maximal precision and we can not go beyond that. Another possibility is to give correct results if possible and use maximal precision otherwise. However, the maximal precision is really a "double precision". Namely, gpc can perform arithmetic at twice of normal machine precision. Which is nice, but expensive: such operation may be significantly slower then normal operations. ATM gpc is rather dumb when predicting needed precision, so even if arguments are small gpc may think that maximal precision is needed. Also, even maximal precision may still give you wrong results.

So, there is rather nasty compromise between correctness and speed. I usuallt go for correctness. However, here speed penalty may be very significant (about 3 times when done right, but may be as high as 20 if maximal precision is slow). So, having optional overflow checking looks more attractive: one can test with overflow checking on and then release with checking off.

Yes, that's my reasoning too. I've always had overflow checking in mind (even though I also cannot work on it in the near future).

Then, I kindly ask to put the following program (with overflow checking) in p/test/todo (to be implemented at some point in the future).

program testsubrange;

type int32 = integer attribute( size = 32); int64 = integer attribute( size = 64); millionbytes = array[ 1..1000000] of byte;

var i: int32;

procedure P( size: int64); begin WriteLn ('size = ', size) end;

begin i:= 3658; P( i * SizeOf( millionbytes)); end.

And, of course, there should always be a way to force evaluation in higher precision if needed. In GPC/BP modes, type-casting one operand is a common way (also common in BP code). In ISO mode, we don't have such a way, AFAICS. OTOH, ISO doesn't support types larger than `Integer' anyway.

But typecasting the SizeOf operand doesn't work, e.g.

program testsubrange;

type int32 = integer attribute( size = 32); int64 = integer attribute( size = 64); millionbytes = array[ 1..1000000] of byte;

var i: int32;

procedure P( size: int64); begin if size = 3658000000 then WriteLn ('OK') else WriteLn ('failed: ', 'size = ', size) end;

begin i:= 3658; P( i * int64( SizeOf( millionbytes))); end.

Typecasting the variable operand (i) does work.

Regards,

Adriaan van Os