[M3devel] recent m3gdb does not want to compile

[Jay]

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.

 

 

The code translates like this:

 

 

Modula-3:

 

 

Foo.i3:

 

 

INTERFACE Foo;

 

 

PROCEDURE GetI() : INTEGER;

PROCEDURE GetJ() : INTEGER;

 

 

END Foo.

 

 

Foo.m3:

 

 

MODULE Foo;

 

 

VAR i, j: INTEGER;

 

 

PROCEDURE GetI() = BEGIN RETURN i; END GetI;

PROCEDURE GetJ() = BEGIN RETURN j; END GetJ;

 

 

C:

 

 

foo.h:

 

 

ptrdiff_t Foo__GetI(void);

ptrdiff_t Foo__GetJ(void);

 

 

foo.c:

 

 

struct

{

  int i, j;

} Foo_M3;

 

 

ptrdiff_t Foo__GetI(void) { return Foo_M3.i; }

 

ptrdiff_t Foo__GetJ(void) { return Foo_M3.j; }

 

 

I personally would much prefer one of:

 

 

 

static int i, j;

 

 

ptrdiff_t Foo__GetI(void) { return i; }

 

 

ptrdiff_t Foo__GetJ(void) { return j; }

 

 

or:

 

 

int Foo_i, Foo_j;

 

 

ptrdiff_t Foo__GetI(void) { return Foo_i; }

 

 

ptrdiff_t Foo__GetJ(void) { return Foo_j; }

 

 

or two underscores.

 

 

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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090610/63bbd22e/attachment-0002.html>