[Bug target/49202] New: MMIX: Wrong debugging information generated (UNKNOWN: length 2)

2011-05-27 Thread n...@script-solution.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49202

   Summary: MMIX: Wrong debugging information generated (UNKNOWN:
length 2)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n...@script-solution.de
  Host: Ubuntu on x86_64
Target: MMIX
 Build: gcc-4.6.0 with binutils-2.21


Created attachment 24381
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24381
Generated object file

Some C constructs seem to cause wrong debugging information. That is especially
a problem, because gdb ignores all the following information, so that debugging
is impossible (line by line in C source).

For example, the following C source causes the problem:

static int strncmpx(const char *str1,const char *str2,int count) {
int rem = count;
while(*str1 && *str2 && rem-- > 0) {
if(*str1++ != *str2++)
return str1[-1] < str2[-1] ? -1 : 1;
}
if(rem <= 0)
return 0;
if(*str1 && !*str2)
return 1;
return -1;
}

int main(void) {
strncmpx("foo","bar",3);
return 0;
}


Compiling this file and reading the line number information results in:
$ mmix-elf-escape-gcc -o t.o -c t.c -g
$ mmix-elf-escape-readelf --debug-dump=decodedline t.o
readelf: Warning: unable to apply unsupported reloc type 5 to section
debug_line
Decoded dump of debug contents of section .debug_line:

CU: t.c:
File nameLine numberStarting address
t.c1   0

t.c20x28
t.c30x38
t.c40x3c
t.c50xa8
UNKNOWN: length 2
t.c50xe0
UNKNOWN: length 2
t.c50xe8
UNKNOWN: length 2
t.c50xec
UNKNOWN: length 2
t.c30xf0
UNKNOWN: length 2
t.c3   0x10c
UNKNOWN: length 2
t.c3   0x128
t.c7   0x16c
t.c8   0x184
t.c9   0x18c
UNKNOWN: length 2
t.c9   0x1a8
t.c   10   0x1c4
t.c   11   0x1cc
t.c   12   0x1d0
t.c   14   0x1dc
t.c   15   0x1ec
t.c   16   0x218
t.c   17   0x21c


I've attached the object file t.o.

[Bug target/49211] New: MMIX: Code generation broken, when using global variables

2011-05-28 Thread n...@script-solution.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49211

   Summary: MMIX: Code generation broken, when using global
variables
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n...@script-solution.de
  Host: Ubuntu on x86_64
Target: MMIX
 Build: gcc-4.6.0 with binutils-2.21


Created attachment 24386
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24386
Contains the object-file and the executable

I hope it is no missunderstanding, but as it seems, the code generation is
wrong when using global variables (I'm wondering because it is such a basic
thing).

For example, take the following C file:

struct foo {
int x,y;
};

static struct foo f;
static int x;

static void func1(int *i) {
}
static void func2(struct foo *pf) {
}

int main(void) {
int a;
f.x = 0;
f.y = 1;
x = 2;
func1(&x);
func1(&a);
func2(&f);
return 0;
}


I'm using the following commands to build the executable:
$ mmix-elf-escape-gcc -o test.o -c test.c
$ mmix-elf-escape-gcc -nostdlib -o test test.o

The disassembly for the main-function is:

0040 :
  40:27fefe10 subu $254,$254,16
  44:affdfe08 stou $253,$254,8
  48:23fdfe10 addu $253,$254,16
  4c:fe04 get $0,rJ
  50:e301 setl $1,0x0
  54:ab01fe00 sttu $1,$254,0
  58:e3010001 setl $1,0x1
  5c:ab01fe04 sttu $1,$254,4
  60:e3010002 setl $1,0x2
  64:ab01fe08 sttu $1,$254,8
  68:2303fe08 addu $3,$254,8
  6c:f302ffe5 pushj $2,0 <_start.>
  70:f604 put rJ,$0
  74:2701fd0c subu $1,$253,12
  78:c1030100 set $3,$1
  7c:f302ffe1 pushj $2,0 <_start.>
  80:f604 put rJ,$0
  84:2303fe00 addu $3,$254,0
  88:f302ffe6 pushj $2,20 
  8c:f604 put rJ,$0
  90:e300 setl $0,0x0
  94:8dfdfe08 ldo $253,$254,8
  98:23fefe10 addu $254,$254,16
  9c:f801 pop 1,0


That means, the code expects, that f is located at $254, offset 0. But $254 is
the frame-pointer according to
http://www.bitrange.com/mmix/mmixfest-2001/mmixabi.html. The example shows a
few other usages, that are wrong for the same reason. Note that it is correct
for the local variable.

For the case that it helps, I've attached the object file and the executable.

I hope that the fix is easy. It would be really nice to know shortly how to
resolve that, because before that, I think one can't do anything useful with
gcc for MMIX :/

[Bug target/49211] MMIX: Code generation broken, when using global variables

2011-05-28 Thread n...@script-solution.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49211

Nils Asmussen  changed:

   What|Removed |Added

   Severity|normal  |blocker

[Bug target/49211] MMIX: Code generation broken, when using global variables

2011-05-30 Thread n...@script-solution.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49211

--- Comment #3 from Nils Asmussen  2011-05-30 14:47:40 
UTC ---
Thanks for your reply!

Perhaps I miss something, but I've no idea how that should work. Regardless of
whether $254 is initialized previously or not (in my case, it's a bootloader,
so there is no stdlib and no crt*, but I have to do that myself), using the
stack-pointer to access global variables can't work, right? Lets suppose, that
the offset in main is correct. That would mean, that x is located at $254 + 8.
But $254 is changed (of course) at the beginning and end of a function (and
nowhere else). If func2 accesses x as well, gcc generates code to access it at
$254 + 8. So, it expects it to be always at offset 8 from $254, but of course
that can't work, because $254 changes.

[Bug target/49211] MMIX: Code generation broken, when using global variables

2011-05-30 Thread n...@script-solution.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49211

--- Comment #5 from Nils Asmussen  2011-05-30 15:22:37 
UTC ---
> Again, I suggest you have a look at crtn.asm, in particular these lines:
> 
> % This must be the last file on the link-line, allocating global registers
> % from the top.
> 
> % Register $254 is the stack-pointer.
> sp GREG
> 
> So, if you leave that out, the global-register-allocation machinery in the
> linker will allocate registers starting from the topmost, which is $254 ($255
> being a scratch register).

Oh, ok. I thought in a different direction :/
Then it's perfectly clear. Thanks!

[Bug target/49202] MMIX: Wrong debugging information generated (UNKNOWN: length 2)

2011-07-07 Thread n...@script-solution.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49202

--- Comment #2 from Nils Asmussen  2011-07-07 23:10:32 
UTC ---
(In reply to comment #1)
> I hope to check this some time in the next four weeks...
> At a glance, it might be a binutils issue, with the relocs message.
Thanks.

I don't know if it helps, but a workaround is to remove the lines 22031,22032
of gcc/dwarf2out.c:
if (SUPPORTS_DISCRIMINATOR && discriminator != 0)
fprintf (asm_out_file, " discriminator %d", discriminator);

This way, the unknown debugging information is gone and debugging using gdb
works.