[M3devel] recent m3gdb does not want to compile

[Elmar Stellnberger]

Even if all the global variables are put into one large struct it should
be possible to read this struct via gdb. Unfortunately that does not
seem to be the case. Let us consider a small sample program in this regard:

MODULE GlobVars EXPORTS Main;

VAR aaa, bbb, ccc, ddd : INTEGER := 1;
    ttt : TEXT := "SampleText";

BEGIN
  bbb := 2;
  ccc := bbb + aaa;
  ddd := ccc + bbb;
END GlobVars.

If I look at the intermediate zero address code there is a well defined
record for all the globals:
...
	# module global data
	declare_segment	 M_GlobVars -1 v.1
...
	  load_integer	 2
	  store		 v.1 48 Int
					  -----LINE 8  -----
	  load		 v.1 48 Int
	  load		 v.1 44 Int
	  add		 Int
	  store		 v.1 52 Int
...
	# global data type descriptor
	declare_record	 -1 1248 6
	declare_field	 M3_MAIN 320 32 2071511887
	declare_field	 aaa 352 32 425470580
	declare_field	 bbb 384 32 425470580
	declare_field	 ccc 416 32 425470580
	declare_field	 ddd 448 32 425470580
	declare_field	 ttt 480 32 1358456180
...
whereby the record offsets in the data type definition are bit oriented
and have to be devided by eight: 352/8 = 44  (var. aaa)

  The corresponding assembler code looks like the following:
	movl	MM_GlobVars at GOT(%ebx), %eax
	movl	$2, 48(%eax)				# bbb:=2

However using gdb I can not access any of the members of the MM_GlobVars
struct
(gdb) p MM_GlobVars.aaa
There is no member named aaa.
(gdb) p MM_GlobVars
$18 = {<No data fields>}

  Trying to access our globals directly via their offsets listed in the
.mc and .ms files worked at least although there seems to exist a quite
strange mismatch. At first I had to subtract from MM_GlobVars rather
than adding the offset. Secondly I had to interpret the offset as hex
number although it is clear that in the .mc-file offsets are meant as
plain decimal integer numbers (i.e. 0x48=72, but 48 was decimal just
before!: i.e. 48*8=384 and not 0x48*0x8=0x384)

p *((int*)((void*)MM_GlobVars-72
$16 = 1

p *((int*)((void*)MM_GlobVars-76
$17 = 2


 Apparently the inability to access global variables via gdb as members
of the module structure may be a flaw m3cc; right?
... but what about the add/sub dec/hex mismatch from above?




Jay schrieb:
> The global variable behavior I think I understand, and I believe the original authors did it this way on purpose, but I agree it seems quite bad.
>   
> 
> The way the code is generated, all the internal globals for a module are in one large struct, per module.
> 
> There aren't symbols for each one.
> 
>   
> 
>  
> 
> Can anyone explain why it is done this way? And why it shouldn't be changed to how I showed?
> 
>  
> 
> Here are some advantages/disadvanges:
> 
>   symbols, debuggability, as discussed 
> 
>   The current way pretty much guaranteeds none of the data gets dead-stripped, for better and worse.
> 
>     But really, even if you changed it to "my way", there's probably another bit needed on the data to dead-strip it,
> 
>     so that behavior can be preserved, for better and worse.
> 
>   "My way" probably also allows for not using bitfields in load/store, in fact, the offseting would often go away too.
> 
>  
> 
>  
> 
>> Should I compile m3gdb towards 32bit on an x86_64 platform if the
>> m3build I am using is 32bit?
> 
>  
> 
>  
> 
> It should build either way, but for it to be useful, yes, I expect so.
> 
> I believe current versions of gdb can have multiple targets though.
> 
>  
> 
>  
> 
>  - Jay
> 
>  
>> Date: Wed, 10 Jun 2009 15:26:09 +0100
>> From: estellnb at yahoo.de
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] recent m3gdb does not want to compile
>>
>> For any kind of reason recent m3gdbs refuse to compile at me:
>>
>> ../gdb/configure
>> ...
>> checking for x86_64-unknown-linux-gnu-ar... no
>> checking for ar... ar
>> ...
>>
>>> which ar
>> /usr/bin/ar
>>
>> setting --bindir to /usr/bin or /usr does not help.
>> full error log: see attachement
>>
>> Should I compile m3gdb towards 32bit on an x86_64 platform if the
>> m3build I am using is 32bit?
>>
>> Besides this I am in wonder why a plain gdb can not access global
>> Modula-3 variables using PM3/EZM3 although I have specified -gstabs in
>> m3config/src/COMMON:
>> ASM = ["as","--32","-gstabs","-o"] % Assembler
>> DEBUG_FLAG = "-gstabs" % debugging info
>> BDEBUG_FLAG = "-gstabs" % debugging info
>> LDEBUG_FLAG = "-gstabs"
>>
>> i.e.
>>> gdb -batch --directory=
>> --directory=/home/elm/m3/Benchmark/LINUXLIBC6/../src -ex 'info
>> variables' /home/elm/m3/Benchmark/LINUXLIBC6/./pureDCT-queue >smbls
>>
>>> grep myglobal smbls -> nothing found
>