bathos-mcuio-kl25z / Ubuntu 14.x / GNU Binutils preventing Unix config from linking bathos.o

[jwinarske]

bathos.o not linking properly due to version_data.o not being the same format as the other object files.

GNU objcopy (GNU Binutils for Ubuntu) 2.24

objcopy --redefine-sym _binary__tmp_filenxkir4_start=version_string -I binary -O elf64-x86-64 /tmp/filenxkir4 version_data.o

lilsprout@jollygreen:~/bathos-mcuio-kl25z$ objdump -d version_data.o |grep format objdump: version_data.o: file format elf64-little

Output format should be: elf64-x86-64

[ciminaghi]

On Wed, May 13, 2015 at 10:32:22PM -0700, Joel Winarske wrote:

bathos.o not linking properly due to version_data.o not being the same format as the other object files.

GNU objcopy (GNU Binutils for Ubuntu) 2.24

objcopy --redefine-sym _binary__tmp_filenxkir4_start=version_string -I binary -O elf64-x86-64 /tmp/filenxkir4 version_data.o

lilsprout@jollygreen:~/bathos-mcuio-kl25z$ objdump -d version_data.o |grep format objdump: version_data.o: file format elf64-little

Output format should be: elf64-x86-64

mmmm, adding set -x on top of scripts/gen_version_data I see:

objcopy --redefine-sym _binary__tmp_file0InB1P_start=version_string -I binary -O elf64-x86-64 /tmp/file0InB1P version_data.o

-O looks correct to me, but:

ciminaghi@dello:/home/develop/yun/riordino-git/bathos-mcuio$ objdump -h version_data.o

version_data.o: file format elf64-little

Sections: Idx Name Size VMA LMA File off Algn 0 .data 00000045 0000000000000000 0000000000000000 00000040 2**0 CONTENTS, ALLOC, LOAD, DATA

:-(

To get the right format, I've got to add a -B i386:

diff --git a/scripts/gen_version_data b/scripts/gen_version_data index 0c27b7d..6262d12 100755 --- a/scripts/gen_version_data +++ b/scripts/gen_version_data @@ -8,6 +8,7 @@ fmt=$2 out=$3

[ "$ARCH" = arm ] && BARG="-B $ARCH" +[ "$ARCH" = unix ] && BARG="-B i386"

f=$(tempfile)

ciminaghi@dello:/home/develop/yun/riordino-git/bathos-mcuio$ objdump -h version_data.o | grep format version_data.o: file format elf64-x86-64

and no complaints from the linker about the format anymore. There are two problems now:

• i386 is not correct, because you could build bathos on a computer which is not an x86 (yes, I know, this is very rare but I like to do things the right way whenever I can).
• There are more issues to fix on the unix port.

So I think it will take some time to fix arch-unix.

For the moment, I've just pushed a unix-restoration branch with some commits fixing the most obvious issues:

746592b UNIX: HACK: scritps/gen_version_data: add -B i386 to objcopy cmdline 69748da UNIX: HACK: pipe.c: define MAX_BATHOS_PIPES dad3b94 UNIX: arch-unix/io.c: include <bathos/pipe.h> 596d251 UNIX: get rid of HZ define cef19cc UNIX: define PROGMEM

Now I've just one linker error:

bathos.o: In function idle': /home/develop/yun/riordino-git/bathos-mcuio/arch-unix/idle.c:39: undefined reference tosys_timer_get_next_tick'

We'll see ....

Thanks Davide

[ciminaghi]

On Wed, May 13, 2015 at 10:32:22PM -0700, Joel Winarske wrote:

bathos.o not linking properly due to version_data.o not being the same format as the other object files.

GNU objcopy (GNU Binutils for Ubuntu) 2.24

objcopy --redefine-sym _binary__tmp_filenxkir4_start=version_string -I binary -O elf64-x86-64 /tmp/filenxkir4 version_data.o

lilsprout@jollygreen:~/bathos-mcuio-kl25z$ objdump -d version_data.o |grep format objdump: version_data.o: file format elf64-little

Output format should be: elf64-x86-64

Hi,

I've just pushed some more commits (unix-restoration). arch-unix is now alive again (for me, at least):

make clean make unix_defconfig make

For the moment, I've just left the "traditional" bathos task-uart enabled, no mcuio. You should see this when running the program:

ciminaghi@dello:/home/develop/yun/riordino-git/bathos-mcuio$ ./bathos system_timer_init Hello, Bathos is speaking (6affe23 built on May 14 2015) .S minute! ....S....S....S....S....S....S....S....S....S....S. ...S....S....S....S....S....S....S....S....S....S. ...S....S....S..^C

Please consider that many commits are marked as "HACK", so they're just temporary and need time to be made more correct. However, I think what we have now is better than nothing. By the way, periodic tasks also stress the bathos allocator (see lib/allocator.c) which actually needs some accurate testing, maybe arch-unix is the right place to do that.

As far as mcuio is concerned, arch-unix could also be useful for testing and debugging.

Davide

[jwinarske]

Working here on amd64 Ubuntu :) I'll leave issue open until you feel the hacks have been worked out.

Joel

[ciminaghi]

On Thu, May 14, 2015 at 09:04:33AM -0700, Joel Winarske wrote:

Working here on amd64 Ubuntu :) I'll leave issue open until you feel the hacks have been worked out.

I don't know what you're trying to do (this is of course your business), but I think it would be nice to provide some "simulated hw" accessible via mcuio under arch-unix. For instance virtual gpios which you can toggle via mcuio .... . This would be useful for demo and debug/test purposes when you have no real hw available.

I actually used arch-unix for my first tests when I wrote mcuio (it was too hard debugging on the atmega directly, so unix was really a good solution). If you want to do mcuio test/debugging under arch-unix, then you might be interested in reading this:

https://github.com/ciminaghi/linux-3.3.8/blob/davide-irqmsg-141016/Documentation/mcuio/tests.txt

Of course I'm not sure everything still works, because things have changed quite a bit since I wrote that document. Still, I think it is worth reading if you haven't already done that.

Thanks a lot for your feedback, I really appreciate it. Comments, bug reports, patches and so on are always welcome :-)

Regards Davide