[M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?)

[Rodney M. Bates]

Mika Nystrom wrote:
> The weird thing is that it works really well SOMETIMES.
>
> Are there any workarounds?  Where would I go poke if I wanted to fix it?
>   
Look at the most recent changes to gdbtypes.h and m3-lang.c.
Prior to this, m3gdb was segfaulting on requests to print floating
values.

I see I have a change to c-valprint.c that is not checked in:

rodney at yellowstone:~/proj/m3/cm3-new/cm3/m3-sys/m3gdb/gdb/gdb$ ll 
c-valprint.c
-rw-r--r-- 1 rodney rodney 18464 2009-02-26 16:08 c-valprint.c
rodney at yellowstone:~/proj/m3/cm3-new/cm3/m3-sys/m3gdb/gdb/gdb$ cvs diff 
c-valprint.c
Index: c-valprint.c
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3gdb/gdb/gdb/c-valprint.c,v
retrieving revision 1.3
diff -r1.3 c-valprint.c
427a428,432
 > #ifdef _LANG_m3
 >     case TYPE_CODE_M3_REAL:
 >     case TYPE_CODE_M3_LONGREAL:
 >     case TYPE_CODE_M3_EXTENDED:
 > #endif

However, this just forces it through a path that prints *really* wrong 
values, which
is no doubt why I didn't check it in.  c-valprint.c is the place to 
start looking.  I will
try to look at this too, but may not get time for a while.

> My code is mostly floating point (double precision).  I find myself typing
> garbage like 
>
> print (double *)(M3_adsf23_myVar+8)
>
> into the normal C gdb....
>
> In m3gdb I am now getting the following error:
>
> (m3gdb) print self.srThreshold
> $2 = Invalid C/C++ type code 44 in symbol table.
>
> This is trying to print a field of type LONGREAL in an OBJECT:
>
> (m3gdb) print self
> $3 = (*16_14838244*) OBJECT orderManager = 16_148382ec; marketDataManager = 16_14838224; tickers = 16_14838ab4; 
>     limitsMap = NIL; orderSizeMap = NIL; rangeMult = ; invTilt = ; perfSmooth = ; times = {RECORD hour = 10; minute = 12; 
>     second = 0;  END, RECORD hour = 15; minute = 55; second = 0;  END, RECORD hour = 15; minute = 30; second = 0;  END, 
>     RECORD hour = 9; minute = 30; second = 0;  END, RECORD hour = 16; minute = 0; second = 0;  END}; tz = 16_1a7bc7b0; 
>     midnites = 16_1a7bc7dc; firstPeriod = 12638; initialPeriods = 390; limitsMap = 16_14838b18; orderSizeMap = 16_14838b38; 
>     singleStockMarketMaker = NIL; ssTbl = 16_14833818; unitsPortfolioTilt = ; portTiltMode = UNITS; srThreshold = ; 
>     dollarUnit = ; unitsPortTilt = ; grossLimit = ; overnightLimitMultiplier = ; rangeMultiplier = ; closeSmooth = ;  END
>
>     Mika
>
> "Rodney M. Bates" writes:
>   
>> Floating point values in m3gdb is one area I have never done any
>> work on at all, but I have been aware for a long time that it probably
>> needs some.  It just uses stock gdb's code, which also just uses
>> the C builtin arithmetic on C floating types.  At the very least, the
>> mapping between C's two and Modula-3's three floating types, on
>> the various targets, is purely an accident right now.  I recall there
>> is something wrong in the formatting too.
>>
>> Mika Nystrom wrote:
>> Hi Modula-3ers, especially Tony,
>>     
>>> I'm seeing the following behavior a lot in a program I'm running:
>>>
>>> #0  0x68ecbba7 in gettimeofday () from /lib/libc.so.5
>>> #1  0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16
>>> #2  0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code 30 in symbol table.
>>> ) at ../src/runtime/common/RTCollector.m3:674
>>> #3  0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code 46 in symbol table.
>>> ) at ../src/runtime/common/RTCollector.m3:2271
>>> #4  0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol table.
>>> )
>>>     at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/libm3/src/sortedtable/SortedTable.mg:145
>>>
>>> Is it normal for CheckLoadTracedRef to make system calls?
>>>
>>> Hmm, why is it even doing CheckLoadTracedRef?  Here's the code (from SortedTable.mg):
>>>
>>>
>>> PROCEDURE Get (           tbl : Default;
>>>                READONLY   k   : Key.T;
>>>                VAR(*OUT*) v   : Value.T): BOOLEAN =
>>>   VAR
>>>     x   : Node := tbl.h.hi;
>>>     cmp : Cmp;
>>>   BEGIN
>>>     WHILE (x # NIL) DO
>>>       cmp := tbl.keyCompare (k, x.key);
>>>       IF cmp = 0 THEN  v := x.value;  RETURN TRUE; END;
>>>       IF (cmp < 0)
>>>         THEN x := x.lo; (* line 145 *)
>>>         ELSE x := x.hi;
>>>       END;
>>>     END;
>>>     RETURN FALSE;
>>>   END Get;
>>>
>>> where Node is defined as 
>>>
>>> TYPE
>>>   Node = REF RECORD
>>>     key     : Key.T;
>>>     value   : Value.T;
>>>     lo      : Node := NIL;
>>>     hi      : Node := NIL;
>>>     priority: INTEGER    (* random num; tree is a heap on these *)  
>>>   END;
>>>
>>> It seems odd to me that, under these circumstances, x := x.lo would
>>> cause any sort of checking activity...
>>>
>>> I'm using a CM3 that's about a month old, on FreeBSD4.
>>>
>>>      Mika
>>>
>>> P.S. Needless to say, the code in question runs about 10x faster under
>>> PM3 than with this relatively new CM3...  but my m3gdb is having trouble
>>> with PM3's LONGREALs for some reason.
>>>
>>>   
>>>       
>
>