Debugging ARM programs inside QEMU

Posted on 2010/08/17

Recently I wanted to debug a Linux program running inside an ARM system emulated with QEMU. I went into some troubles, so I’m going to write here the procedure that worked for me. I wanted to use gdbserver to run a program inside QEMU, and then connect to it from a GDB instance running on my PC, using a TCP link. gdbserver is a piece of software that implements some of the GDB functionalities (the debugging stubs) and then offers the possibility to connect to a full GDB instance through the network (or through a serial port). What I wanted to obtain is illustrated in the following figure.

Using gdbserver inside QEMU

The color blue indicates software compiled to run on my Ubuntu PC (32-bit x86) while the color green indicates software compiled to run on ARM. qemu-system-arm is the software that emulates a VersatilePB platform; I tried to use the one that can be installed through Ubuntu repositories (the package is qemu-kvm-extras) but it froze running the last version of Linux (2.6.35). For this reason I decided to compile the upstream version and use that one. The GDB server and “client” come from the CodeSourcery compiler collection for ARM, as well as the compiler used to cross-compile the software for ARM. The program I’ll debug in this example is the simple GNU Hello, that doesn’t do very much beyond printing “Hello World”, but is a nice example of cross-compilation with GNU Autotools.

Prerequisites

In order to follow this procedure, I installed:

CodeSourcery GNU/Linux toolchain for ARM
The native x86 toolchain (build-essentials package in Ubuntu) to compile QEMU
DDD as a graphic interface to the debugger
cpio, an utility to create the Linux filesystem image.
the package libncurses5-dev to run the menu configurations of both Linux kernel and Busybox
libsdl-dev and zlib1g-dev to compile QEMU

$ sudo apt-get install build-essential ddd cpio libncurses5-dev libsdl-dev zlib1g-dev
$ wget http://www.codesourcery.com/sgpp/lite/arm/portal/package6490/public/arm-none-linux-gnueabi/arm-2010q1-202-arm-none-linux-gnueabi.bin
$ chmod +x arm-2010q1-202-arm-none-linux-gnueabi.bin
$ ./arm-2010q1-202-arm-none-linux-gnueabi.bin

I installed the toolchain in the default directory “~/CodeSourcery”. The gdbserver executable in my case can be found at the path “/home/francesco/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/usr/bin/gdbserver”.

Note that the following procedure is run in a dedicated folder, and no root access is required from now on. At the end of the procedure about 1 Gigabyte of hard disk space was used.

Linux Kernel

First of all, I took the new kernel version from the official repositories.

$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.35.tar.bz2
$ tar xjf linux-2.6.35.tar.bz2
$ cd linux-2.6.35/
$ make ARCH=arm versatile_defconfig
$ make ARCH=arm menuconfig

When the menu appears, I go into the “Kernel Features” section and enable EABI support; then I exit (saving the configuration) and compile:

$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- all
$ cd ..

The result is a compressed kernel image in “./linux-2.6.35/arch/arm/boot/zImage”.

Busybox

Next, I take the latest version of Busybox; in a previous tutorial I compiled it statically, but this time I will not, because gdbserver (that I plan to use) needs shared libraries anyway.

$ wget http://busybox.net/downloads/busybox-1.17.1.tar.bz2
$ tar xjf busybox-1.17.1.tar.bz2
$ cd busybox-1.17.1
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- defconfig
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- install
$ cd ..

The result is the folder “busybox-1.17.1/_install”, containing a minimal root filesystem that lacks shared libraries.

QEMU

I recompiled from source only the QEMU binaries needed to emulate an ARM system.

$ wget http://download.savannah.gnu.org/releases/qemu/qemu-0.12.5.tar.gz
$ tar xzf qemu-0.12.5.tar.gz
$ cd qemu-0.12.5
$ ./configure --enable-sdl --disable-kvm --enable-debug --target-list=arm-softmmu
$ ./make
$ cd ..

The relevant result is the program “./qemu-0.12.5/arm-softmmu/qemu-system-arm” that will be used to emulate the VersatilePB platform.

GNU Hello

This package needs to be configured for cross-compilation; turns out it’s very easy to do: it needs just the prefix of the cross-compiler.

$ wget http://ftp.gnu.org/gnu/hello/hello-2.6.tar.gz
$ tar xzf hello-2.6.tar.gz
$ cd hello-2.6
$ ./configure --host=arm-none-linux-gnueabi
$ make
$ cd ..

The result is the ARM-executable “hello-2.6/src/hello”.

Complete the filesystem

All the ARM binaries involved (busybox, gdbserver, hello) need shared libraries. The Codesourcery toolchain offers these libraries in a subfolder of its installation. In my case it’s “/home/francesco/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/”. In order to discover what are the needed libraries I used the readelf tool distributed in the CodeSourcery toolchain. In particular, I ran:

$ arm-none-linux-gnueabi-readelf hello-2.6/src/hello -a |grep lib
 [Requesting program interpreter: /lib/ld-linux.so.3]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
00010694  00000216 R_ARM_JUMP_SLOT   0000835c   __libc_start_main
 2: 0000835c     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.4 (2)
 89: 0000844c     4 FUNC    GLOBAL DEFAULT   12 __libc_csu_fini
 91: 0000835c     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@@GLIBC_
 101: 00008450   204 FUNC    GLOBAL DEFAULT   12 __libc_csu_init
 000000: Version: 1  File: libgcc_s.so.1  Cnt: 1
 0x0020: Version: 1  File: libc.so.6  Cnt: 1

The hello binary requires three shared libraries: “ld-linux.so.3″, “libgcc_s.so.1″ and “libc.so.6″. I executed this command for all three binaries, and I copied the required libraries into the Busybox filesystem, together with the gdbserver executable and the hello executable.

$ cd busybox-1.17.1/_install
$ mkdir -p lib
$ cp /home/francesco/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/ld-linux.so.3 lib/
$ cp /home/francesco/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/libgcc_s.so.1 lib/
$ cp /home/francesco/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/libm.so.6 lib/
$ cp /home/francesco/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/libc.so.6 lib/
$ cp /home/francesco/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/libdl.so.2 lib/
$ cp /home/francesco/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/usr/bin/gdbserver usr/bin/
$ cp ../../hello-2.6/src/hello usr/bin/
$ cd ../../

For my experiment I need a working network from the guest ARM system side, so I prepared an initialization script to enable it. Extending from my previous tutorial, here is the script “rcS” that i used.

#!/bin/sh
mount -t proc none /proc
mount -t sysfs none /sys
/sbin/mdev -s
ifconfig lo up
ifconfig eth0 10.0.2.15 netmask 255.255.255.0
route add default gw 10.0.2.1

Next, I copy rcS it inside the “etc/init.d” directory of the Busybox filesystem and create a compressed filesystem image:

$ cd busybox-1.17.1/_install
$ mkdir -p proc sys dev etc etc/init.d
$ cp ../../rcS etc/init.d
$ chmod +x etc/init.d/rcS
$ find . | cpio -o --format=newc | gzip > ../../rootfs.img.gz
$ cd ../../

Running and debugging

Now I have put everything in place:

A compressed kernel image
QEMU
A compressed filesystem image containing:
- Busybox
- rcS initialization script
- GNU Hello binary compiled for ARM
- gdbserver for ARM
- Required shared libraries

To run the plaform the command line is:

$ ./qemu-0.12.5/arm-softmmu/qemu-system-arm -M versatilepb -m 128M -kernel ./linux-2.6.35/arch/arm/boot/zImage -initrd ./rootfs.img.gz -append "root=/dev/ram rdinit=/sbin/init" -redir tcp:1234::1234

The “redir” option will redirect any TCP communication from port 1234 of my Ubuntu PC to port 1234 of the guest ARM system. The system will boot, and a console can be opened with root access. Inside the bash prompt, I run the debugging server:

# gdbserver --multi 10.0.2.15:1234

This command will launch a server that waits for a GDB connection from port 1234. On my PC I open the debugger:

$ ddd --debugger arm-none-linux-gnueabi-gdb

It is also possible to run the arm-none-linux-gnueabi-gdb command alone or connected to another front-end. In order to debug the remote program, I need to tell GDB to consider the ARM shared libraries instead of the local ones (that are for 32-bit x86); otherwise on execution the debugger will complain that the libraries don’t match.

set solib-absolute-prefix nonexistantpath
set solib-search-path /home/francesco/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/
file ./hello-2.6/src/hello
target extended-remote localhost:1234
set remote exec-file /usr/bin/hello
break main
run

At this point the debugging goes on as usual.

About these ads

Tagged: ARM, codesourcery, debug, gdb, gnu, helloworld, howto, kernel, linux, qemu, tutorial

Posted in: Embedded

36 Responses “Debugging ARM programs inside QEMU” →

M.Vivek

2011/02/05

Hi Balau,

I ran the steps that you have outlined . But, on doing “run” in the gdb console of ddd, the QEMU
session exits with :
****
…
Please press Enter to activate this console.
/ # gdbserver –multi 10.0.2.15:1234
Listening on port 1234

QEMU: Terminated via GDBstub
***
What could be the issue ?
Regards,
M.Vivek
Balau

2011/02/05

I get your same error if I run QEMU with debug option enabled (for example “-s”). In this way, when you connect with gdb from the outside, you are actually connected to QEMU and not to the gdbserver running inside it. If you did not enable QEMU debug options, maybe you have a QEMU option enabled by default, try using a different port (1235) for both gdbserver and the ddd “target extended-remote” command.
Ram

2011/03/12

Hi,
I followed your step, but last step qemu just hangs. System doesn’t boot.
Balau

2011/03/13

Do you mean that when you run the “qemu-system-arm” command it doesn’t show anything about the Linux kernel booting? Or do you see some messages but at the end there are some errors and it doesn’t show the command shell?
Ram

2011/03/13

After qemu-system-arm command qemu screen appears, but it doesn’t show anything.(Just black screen), no message about booting at all.
I tried booting linux kernel “linux-0.2.ing” provided by qemu site with rootfile system provided by the qenu itself, it works fine.
Ram

2011/03/13

I was trying that with kernel 2.6.37, now I tried with 2.6.35. Now I get error

Kernel Panic – Not syncing : Attempted to kill init !
Balau

2011/03/13

I think you mean the “arm-test-0.2.tar.gz” test containing the arm_root.img file.
Anyway, when you compile the kernel like in my test, what does it say when you run the command “file ./linux-2.6.35/vmlinux”?
Are you using the same version of Linux kernel, QEMU and CodeSourcery toolchain that I’m using?
Balau

2011/03/13

This usually happens when I forget to enable EABI support in the Kernel configuration, so that the kernel tries to execute Busybox binaries and fails, exiting the “init” program.
Ram

2011/03/13

Hey I got it. I didn’t enabled EABI support in Kernel Features.

Thank you.

Best Regards
Ram
Ram

2011/05/24

Hi,
Is it possible to run dynamically linked binary in qemu?
I am trying to run DirectFB test applications in qemu and I have copid all required libraries ( cross-compiled for arm) in /usr/lib, but still I am getting error.

/bin/sh : ./test :not found
Balau

2011/05/24

Have you populated also the C standard libraries and the Linux dynamic loader (ld-linux.so*)?
They are usually provided by the toolchain. For example in CodeSourcery these libraries are in “Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib” and in “Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/usr/lib”
You can see the libraries that a program need by running “readelf -d -l” (or the cross-compiler version of it) on the executable and noting the “program interpreter” and “shared library” lines.
In your case, maybe the “sh” interpreter or the “test” program needs some libraries that have not been copied.
Ram

2011/05/25

Hi,
I have copied all required libraries in /usr/lib ( using the rootfs built according to your post for nfs set up ), but still getting same error.

I can’t execute even simple “hello world” program in qemu-system-arm, unless binary is compiled with -static option.

Is there anything that need to be done at time of building rootfs or kernel image, to enable execution of dynamically linked binaries?
Ram

2011/05/25

Hi,

I got the problem
(ld-linux.so*) need to be in /lib, along with its real library it is pointing to.

Earlier I copied it in /usr/lib

Regards,
Mandar Vaidya

2011/09/21

/bin/sh: arm-none-linux-gnueabi-gcc: command not found

error get while running the make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- all command
please send reply
Balau

2011/09/21

You probably don’t have the toolchain in your PATH.
When you installed CodeSourcery, the installation should have added in your login scripts some lines that add the toolchain directory to the PATH environmental variable, so that the next time you open a terminal they are set correctly and you can run it.

By default the binaries are installed in “~/CodeSourcery/Sourcery_G++_Lite/bin“, so you should check if that directory is contined in the PATH, by running “echo $PATH” in the terminal. To add it manually, the command is:

export PATH="~/CodeSourcery/Sourcery_G++_Lite/bin:${PATH}"

If you installed CodeSourcery into another directory then you need to use that directory instead.
ericwain

2011/09/27

Hi Balau,
After Linux booting, I follow your step to do debug. But I get this error message when I execute
target extended-remote localhost:1234.
warning: unrecognized item “timeout” in “qSupported” response
—————————————————
My ubuntu IP is 192.168.104.3, so I change IP of rcS file to 192.168.104.4

#!/bin/sh
mount -t proc none /proc
mount -t sysfs none /sys
/sbin/mdev -s
ifconfig lo up
ifconfig eth0 192.168.104.4 netmask 255.255.255.0
route add default gw 192.168.104.1
(After booting, it can not ping to 192.168.104.3, why???)

In Qemu:
qemu-system-arm -M versatilepb -m 128M -kernel linux-2.6.35.9/arch/arm/boot/zImage -initrd rootfs.img.gz -append “root=/dev/arm rdinit=/sbin/init” -redir tcp:1234::1234

gdbserver –multi 192.168.104.4:1234

In GDB:
(gdb) set solib-absolute-prefix nonexistantpath
(gdb) set solib-search-path ~/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/
(gdb) file ./hello-2.6/src/hello
Reading symbols from /home/erictsai/workspace/qemu/hello-2.6/src/hello…done.
(gdb) target extended-remote localhost:1234
Remote debugging using localhost:1234
Ignoring packet error, continuing…
warning: unrecognized item “timeout” in “qSupported” response
Ignoring packet error, continuing…
Ignoring packet error, continuing…
Ignoring packet error, continuing…
Ignoring packet error, continuing…

any suggestions for this issue?

Thank you.
Balau

2011/09/27

Your Ubuntu IP does not mean you have to change your rcS. Your guest system is still seeing a “10.0.*.*” network created by QEMU; check this page for more info: QEMU Networking
ericwain

2011/09/28

Hi balau,
According to your reply, I have solved this problem. Thank you. It can trace hello problem now. But when I trace setlocale (LC_ALL, “”) in hello program, gdb will show:

Cannot access memory at address 0×0

Program received signal SIGSEGV, Segmentation fault.
0xe7f001f0 in ?? ()

How can it trace these system calls like setlocale or fprintf?

Again, Can it debug Linux kernel (like start_kernel) under this environment?
Balau

2011/10/02

The SIGSEGV could be a problem in shared libraries.
Try to compile the “hello” program with “CFLAGS=-static make” and see if it gives you the same error.
If it runs OK, then check if you are copying the correct libraries into the busybox filesystem.

To debug the kernel, run qemu-system-arm with “-s -S” options but without the “-redir tcp:1234::1234” option, or at least use a different port, because “-s -S” options start QEMU with a GDB server listening to port 1234.
When QEMU is opened it is freezed waiting for a connection, then you can run “ddd --debugger arm-none-linux-gnueabi-gdb“, and inside the gdb prompt you can run something like:
file linux-2.6.35/vmlinux (to get the Linux debugging symbols)
target remote localhost:1234 (to connect to QEMU)
break start_kernel
continue
ericwain

2011/10/03

Hi Balau,
I set the wrong shared library path.. >_<..
Hello program can be debugged correctly now .
Thank you.
john

2011/11/13

Hi Balau,

Nice tutorial you have there. During the last part when i use run in gdb i bump into some warnings:

(gdb) run
warning: `/lib/libgcc_s.so.1′: Shared library architecture unknown is not compatible with target architecture arm.
warning: .dynamic section for “/lib/libgcc_s.so.1″ is not at the expected address (wrong library or version mismatch?)
warning: `/lib/libc.so.6′: Shared library architecture unknown is not compatible with target architecture arm.
warning: .dynamic section for “/lib/libc.so.6″ is not at the expected address (wrong library or version mismatch?)

is these warning crictical? or i missed something in between =)
Balau

2011/11/13

It seems that gdb is trying to use the libraries of your host PC (which are usually for x86 architectures) instead of the CodeSourcery ones (which are for ARM).

I think that if you use it anyway, the debugger could crash when you reach a library function such as printf.

The “solib-absolute-prefix” command with a non-existant path as the argument should be used to avoid the host libraries, then the “solib-search-path” command should point to the right libraries. Are you sure you ran these commands correctly?
john

2011/11/14

Not so sure though.

GNU DDD 3.3.12 (i386-redhat-linux-gnu), by Dorothea Lütkehaus and Andreas Zeller.
Copyright © 1995-1999 Technische Universität Braunschweig, Germany.
Copyright © 1999-2001 Universität Passau, Germany.
Copyright © 2001 Universität des Saarlandes, Germany.
Copyright © 2001-2004 Free Software Foundation, Inc.
(gdb) pwd
Working directory /home/student.
(gdb) cd verilog_examples/A
verilog_examples/ARM
verilog_examples/AT510
(gdb) cd verilog_examples/ARM/QEMU/
(gdb) pwd
Working directory /home/student/verilog_examples/ARM/QEMU.
(gdb) cd debugging-arm-programs-inside-qemu
(gdb) set solib-absolute-prefix nonexistant
(gdb) set solib-search-path /home/student/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/
(gdb) file ./hello-2.6/src/hello
(gdb) target extended-remote localhost:1234
(gdb) set remote exec-file /usr/bin/hello
(gdb) break main
Breakpoint 1 at 0x8b3c: file hello.c, line 52.
(gdb) run
warning: `/lib/libgcc_s.so.1′: Shared library architecture unknown is not compatible with target architecture arm.
warning: .dynamic section for “/lib/libgcc_s.so.1″ is not at the expected address (wrong library or version mismatch?)
warning: `/lib/libc.so.6′: Shared library architecture unknown is not compatible with target architecture arm.
warning: .dynamic section for “/lib/libc.so.6″ is not at the expected address (wrong library or version mismatch?)

Breakpoint 1, main (argc=1, argv=0xbeefeeb4) at hello.c:52
(gdb)
Balau

2011/11/14

The commands seem OK if “/home/student/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/” contains “libgcc_s.so.1″ and the other libraries.
Are you sure you are using the ARM toolchain GDB and not your PC’s classic gdb?
Try to run “arm-none-linux-gnueabi-gdb” without DDD and see if the error is the same.
The problem is that if you use ARM binutils with x86 binaries or x86 binutils with ARM binaries, the architecture is seen as “unknown”.
Try also to run “arm-none-linux-gnueabi-objdump -f …” on the library files that you copied in “_install/lib”. If the architecture is “UNKNOWN!” then you copied the wrong libraries.
john

2011/11/14

Hi,

Just tested the objdump. the library files seems to be correct

[student@fedora lib]$ arm-none-linux-gnueabi-objdump -f ld-linux.so.3

ld-linux.so.3: file format elf32-littlearm
architecture: arm, flags 0×00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000007a0

[student@fedora lib]$ arm-none-linux-gnueabi-objdump -f lib
libc.so.6* libdl.so.2* libgcc_s.so.1* libm.so.6*
[student@fedora lib]$ arm-none-linux-gnueabi-objdump -f libc.so.6

libc.so.6: file format elf32-littlearm
architecture: arm, flags 0×00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x0001595c

[student@fedora lib]$ arm-none-linux-gnueabi-objdump -f libgcc_s.so.1

libgcc_s.so.1: file format elf32-littlearm
architecture: arm, flags 0×00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000028ec
john

2011/11/14

Hi,

When i used the command without ddd, i get the same error too. @.@

[student@fedora ~]$ arm-none-linux-gnueabi-gdb
GNU gdb (Sourcery G++ Lite 2011.03-41) 7.2.50.20100908-cvs
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “–host=i686-pc-linux-gnu –target=arm-none-linux-gnueabi”.
For bug reporting instructions, please see:
.
(gdb) pwd
Working directory /home/student.
(gdb) cd v
vcs_lab/ verilog_examples/
(gdb) cd verilog_examples/ARM/QEMU/debugging-arm-programs-inside-qemu/
Working directory /home/student/verilog_examples/ARM/QEMU/debugging-arm-programs-inside-qemu.
(gdb) set solib-absolute-prefix nonexistantpath
(gdb) set solib-search-path /home/student/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib/
(gdb) file ./hello-2.6/src/hello
Reading symbols from /home/student/verilog_examples/ARM/QEMU/debugging-arm-programs-inside-qemu/hello-2.6/src/hello…done.
(gdb) target extended-remote localhost:1234
set extended-remote localhoslocalhost:1234: Connection timed out.
(gdb) set extended-remote localhost:1234
No symbol “extended” in current context.
(gdb) target extended-remote localhost:1234
localhost:1234: Connection timed out.
(gdb) set remote exec-file /usr/bin/hello
(gdb) break main
Breakpoint 1 at 0x8b3c: file hello.c, line 52.
(gdb) run
Starting program: /home/student/verilog_examples/ARM/QEMU/debugging-arm-programs-inside-qemu/hello-2.6/src/hello
Don’t know how to run. Try “help target”.
(gdb) run
Starting program: /home/student/verilog_examples/ARM/QEMU/debugging-arm-programs-inside-qemu/hello-2.6/src/hello
Don’t know how to run. Try “help target”.
(gdb) file ./hello-2.6/src/hello
Load new symbol table from “/home/student/verilog_examples/ARM/QEMU/debugging-arm-programs-inside-qemu/hello-2.6/src/hello”? (y or n) y
Reading symbols from /home/student/verilog_examples/ARM/QEMU/debugging-arm-programs-inside-qemu/hello-2.6/src/hello…done.
(gdb) target extended-remote localhost:1234Remote debugging using localhost:1234
(gdb) set remote exec-file /usr/bin/hello
(gdb) break main
Note: breakpoint 1 also set at pc 0x8b3c.
Breakpoint 2 at 0x8b3c: file hello.c, line 52.
(gdb) run
Starting program: /home/student/verilog_examples/ARM/QEMU/debugging-arm-programs-inside-qemu/hello-2.6/src/hello
warning: `/lib/libgcc_s.so.1′: Shared library architecture unknown is not compatible with target architecture arm.
warning: .dynamic section for “/lib/libgcc_s.so.1″ is not at the expected address (wrong library or version mismatch?)
warning: `/lib/libc.so.6′: Shared library architecture unknown is not compatible with target architecture arm.
warning: .dynamic section for “/lib/libc.so.6″ is not at the expected address (wrong library or version mismatch?)

Breakpoint 1, main (argc=1, argv=0xbebb1eb4) at hello.c:52
52 program_name = argv[0];
(gdb)
Balau

2011/11/14

I’m sorry but I think I can’t solve this problem.
It may be something different between your RedHat/Fedora distribution and my Debian/Ubuntu, but I don’t know what it is.
john

2011/11/14

Ohh ok. Thanks for the help =) will let you know if i managed it
Mandar Vaidya

2011/11/16

sir,
how to load(install) the free rtos on qemu for cortex-m3 arm processor.
Balau

2011/11/16

I would like to do it, too, but I never found the time.
In my opinion I would start with this setup:

Using CodeSourcery bare metal toolchain for Cortex-M3

Hoping that freeRTOS has good support for that Luminary Micro core, I would compile one of the demo programs and it will create a binary image that can be passed on with the “-kernel” or with the “-pflash” option of QEMU.
As I said, I never did it so it is just an idea and I don’t know if there are some details that make it impossible/hard to do.
zhenningjohn

2011/12/01

Managed to compile and run it. I just need the latest version of busybox and qemu ^_^