qdos-gcc @ arm

[tcat]

Hi,

Just recompiled `qdos-gcc' on raspberry, but I do miss something on the way.

Code: Select all

$ qdos-gcc hello.c -o hello
Undefined Symbol: ''
hello: dataspace 100 (64)
Undefined Symbols:        1

On my old x86 machine it works as usual.

Any ideas?
Many thanks
Tomas

[tcat]

Simple hello prog.

Code: Select all

# hello.c
#include <stdio.h>

main (int argc, char *argv[])
{
	printf ("%s\n\n", "hello world!");

}

Just assembly gcc phase

Code: Select all

$ qdos-gcc -S hello.c
$ cat hello.s
	.sect	.text
	.sect	.rom
	.sect	.data
	.sect	.bss

;gcc2_compiled
	.sect	.text
LC0:
	.data1	0x68,0x65,0x6c,0x6c,0x6f,0x20,0x77,0x6f,0x72,0x6c,0x64,0x21,0x0
LC1:
	.data1	0x25,0x73,0xa,0xa,0x0
	.align 2
	.extern	 _main
_main:
	link a6,#0
	bsr ___main
	pea LC0
	pea LC1
	bsr _printf
	addq.l #8,sp
L8:
	unlk a6
	rts

Assembler phase

Code: Select all

$ which as
/usr/local/qdos/bin/as68
$ as hello.s

Output object file is missing `_printf' symbol

Code: Select all

$ hd hello.o

00000000  fb 01 07 68 65 6c 6c 6f  2e 6f fb 10 ff ff 04 54  |...hello.o.....T|
00000010  45 58 54 fb 10 ff fe 04  44 41 54 41 fb 10 ff fd  |EXT.....DATA....|
00000020  05 55 44 41 54 41 fb 06  05 5f 6d 61 69 6e 00 00  |.UDATA..._main..|
00000030  00 12 ff ff fb 10 00 03  07 5f 5f 5f 6d 61 69 6e  |.........___main|
00000040  fb 04 ff ff 68 65 6c 6c  6f 20 77 6f 72 6c 64 21  |....hello world!|
00000050  00 25 73 0a 0a 00 4e 56  00 00 4e b9 fb 07 00 00  |.%s...NV..N.....|
00000060  00 00 54 2b 00 03 fb 48  79 fb 07 00 00 00 00 54  |..T+...Hy......T|
00000070  2b ff ff fb 48 79 fb 07  00 00 00 0d 54 2b ff ff  |+...Hy......T+..|
00000080  fb 4e b9 fb 07 00 00 00  00 54 2b 00 04 fb 50 8f  |.N.......T+...P.|
00000090  4e 5e 4e 75 fb 13                                 |N^Nu..|
00000096

While on x86 the same source works, what needs to be changed in `as68' source for raspberry armv7?

I need help.
Many thanks
Tomas

[tofro]

While the original GNU assembler is happy to make everything "global" which isn't known locally, as68 wants to see a ".extern <symbol>" in the source file. This ("\t.extern _printf") is definitely missing in the assembly source file you're showing.

GCC for QL applies a patch to

"gcc-qdos/gcc/config/m68k/m68k.h"

Code: Select all

+#define GLOBAL_ASM_OP ".extern" \
 #define ASM_GLOBALIZE_LABEL(FILE,NAME)	\
   do { fprintf (FILE, "%s ", GLOBAL_ASM_OP);		\
        assemble_name (FILE, NAME);

Did you apply that patch? If yes, I would look around places where the compiler uses that definition.

Another idea: C68 headers ar redefining all sorts of std C symbols - how does your generated assembly code look like when you comment out the "#include stdio_h" directive?

Tobias

[tcat]

Hi Tobias,

re: "gcc-qdos/gcc/config/m68k/m68k.h"
Patch applied to both x86, arm sources.

On x86, same `hello.s' source, assembles and puts out all symbols
_main
__main
_printf

the only symbol with .extern directive really is _main there.

On arm, when I key in by hand _printf in extern directive, it just replaces __main symbol.

Code: Select all

# hello.s
...
.extern  _main,_printf
...

Code: Select all

$ as hello.s
$ hd hello.o
00000000  fb 01 07 68 65 6c 6c 6f  2e 6f fb 10 ff ff 04 54  |...hello.o.....T|
00000010  45 58 54 fb 10 ff fe 04  44 41 54 41 fb 10 ff fd  |EXT.....DATA....|
00000020  05 55 44 41 54 41 fb 06  05 5f 6d 61 69 6e 00 00  |.UDATA..._main..|
00000030  00 12 ff ff fb 10 00 03  07 5f 70 72 69 6e 74 66  |........._printf|
00000040  fb 04 ff ff 68 65 6c 6c  6f 20 77 6f 72 6c 64 21  |....hello world!|
00000050  00 25 73 0a 0a 00 4e 56  00 00 4e b9 fb 07 00 00  |.%s...NV..N.....|
00000060  00 00 54 2b 00 04 fb 48  79 fb 07 00 00 00 00 54  |..T+...Hy......T|
00000070  2b ff ff fb 48 79 fb 07  00 00 00 0d 54 2b ff ff  |+...Hy......T+..|
00000080  fb 4e b9 fb 07 00 00 00  00 54 2b 00 03 fb 50 8f  |.N.......T+...P.|
00000090  4e 5e 4e 75 fb 13 

EDIT
On x86, when I add _printf in extern no change in output of as68, strange

When I comment out # include no change in output on both x86,arm

Tom

[tcat]

Hi,

Started debugging, added `perror()' to `lookup(name)' in `sym.c' presumably dealing with symbols.

EDIT changed perror() to fprintf( stderr, ... )
Output to stderr

Code: Select all

$ as hello.s
LC0
LC1
_main
___main
_printf
L8

So `_printf' is seen, but not dealt with properly, somewhere, somehow.
Not sure if this is any good, anywhere better to look further?

Tomas

[tcat]

In the `main.c' debug code just after `aspass1()' added

Code: Select all

int main(int argc, char *argv[])
{
...
        aspass1();

        SYM *p; char name[12] = {'\0'};
        p = lookup( "_printf" );
        //p = lookup( "___main" );
        cpyname( name, p);
        fprintf( stderr, "%x %x %x %s\n", p, p->flags, p->access, name );
        putsym( p );
...
}

Output

Code: Select all

$ which as
/usr/local/qdos/bin/as
$ as hello.s
dumpsym()
_main
___main
def380 8000 4 _printf

dumsym() called by aspass1() for the TXT segment
it dumps `_main', `___main' symbols, but no `_printf'
symbol `_printf' exists (adr=$def380), is looked up, has $8000=DEFINED flag, and has $4=O_ UNDEF access

dumpsym() walks and dumps all symbols of ( O_UNDEF | O_GLOBAL ) access to object file

_printf is of O_UNDEF access and exists, why it is NOT dumped????

putsym( p ) puts it out at the end of object file, wrong place, but is there at least

[tcat]

Hi,

I am now getting this.

Code: Select all

pi@raspberrypi:~/ql/qdos $ qdos-gcc hello.c -o hello
hello: dataspace 882 (372)

But the binary `hello' does not seem right.

Some analysis>>>
`hello.o' object identical on x86 and arm
`hello' executable 16276 bytes, same size on x86 and arm, but has 216 differences
`libgcc.a' and `libc.a' are not identical on x86 and arm
when I move `libgcc.a' and `libc.a' from arm to x86, `hello' is functional when linked against arm libs on x86, so is when linked against x86 libs

May this point to a problem with `ld' SROFF linker on arm, anyone having a functional `ld' on arm?

Many thanks
Tomas

[tcat]

Hi,

With only little understanding, I put on both machines x86/arm, `libc.a', `glibcc.a' created on arm. There was some debug hint left in `calc_xref()' function, that I uncommented.

Linker phase, with creating MAP, and outputting xref, on arm, and on x86, respectively.

Code: Select all

pi@raspberrypi:~/ql/qdos $ /usr/local/qdos/bin/ld -M hello.o -o hello -lgcc > xref
hello: dataspace 882 (372)

`xref' and `xref.x86' have both 1006 lines
`xref' on arm is totally missing UDATA, DATA, TEXT section info
see below sample of `diff xref xref.x86', and `xref.zip' with entire output

Code: Select all

< XREF at      5E8        8
< 
< XREF at      5EE        C
< 
< XREF at      5F4        0
< 
---
> XREF at      5E8       40
> UDATA/b712ad92
> XREF at      5EE       44
> UDATA/b712ad92
> XREF at      5F4       38
> UDATA/b712ad92

xref.zip

linker xref and MAP

(11.09 KiB) Downloaded 134 times

Is likely the linker problem then?
What is XREF, what is UDATA, DATA, TEXT. Why is not calculated identically on both machines, when using same libs, and same version of ld?

Thanks
Tomas

[tcat]

Hi,

Seems almost there.

Code: Select all

pi@raspberrypi:~/ql/qdos $ qdos-gcc hello.c -o hello
hello: dataspace 882 (372)
pi@raspberrypi:~/ql/qdos $ cmp hello x86/hello
pi@raspberrypi:~/ql/qdos $ cp hello ~/mdv2

hello executable

hello.png (10.72 KiB) Viewed 2974 times

Testing further...

Tom

[XorA]

Hi,

Seems almost there.

Code: Select all

pi@raspberrypi:~/ql/qdos $ qdos-gcc hello.c -o hello
hello: dataspace 882 (372)
pi@raspberrypi:~/ql/qdos $ cmp hello x86/hello
pi@raspberrypi:~/ql/qdos $ cp hello ~/mdv2

hello.png
Testing further...

Tom

How did your testing go?