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

[Mika Nystrom]

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?

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.
>>
>>