* Running programs on aarch64 simulator @ 2020-05-08 13:44 Joel Sherrill 2020-05-08 16:09 ` Simon Marchi 2020-05-08 16:16 ` Luis Machado 0 siblings, 2 replies; 12+ messages in thread From: Joel Sherrill @ 2020-05-08 13:44 UTC (permalink / raw) To: gdb Hi Can someone please provide an example of how to compile a program to run on the aarch64 simulator in gdb? The simple "aarch64-elf main.c -o main" does not link and appears to be missing libgloss type symbols. I asked on newlib but got no response. I'm hoping someone here knows. Thanks. --joel RTEMS ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-08 13:44 Running programs on aarch64 simulator Joel Sherrill @ 2020-05-08 16:09 ` Simon Marchi 2020-05-08 16:57 ` Joel Sherrill 2020-05-08 16:16 ` Luis Machado 1 sibling, 1 reply; 12+ messages in thread From: Simon Marchi @ 2020-05-08 16:09 UTC (permalink / raw) To: joel, gdb On 2020-05-08 9:44 a.m., Joel Sherrill wrote: > Hi > > Can someone please provide an example of how to compile a program to run on > the aarch64 simulator in gdb? The simple "aarch64-elf main.c -o main" does > not link and appears to be missing libgloss type symbols. > > I asked on newlib but got no response. I'm hoping someone here knows. > > Thanks. > > --joel > RTEMS > Hi Joel, If I just compile a "main" function with the bare-metal aarch64 or arm compiler, it does indeed complain about a missing _exit function: <snip>/gcc/aarch64-none-elf/9.2.1/../../../../aarch64-none-elf/lib/libg.a(lib_a-exit.o): in function `exit': <snip>/build/src/newlib-cygwin/newlib/libc/stdlib/exit.c:64: undefined reference to `_exit' I think this is expected, as the runtime requires you to provide some implementation for _exit, in other words what you want to do when the program has finished. Maybe shut down the board, reset it, shut down the simulator, that's use case-specific. libgloss indeed provides an implementation, so I guess you could include that in your program: https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=libgloss/aarch64/_exit.c;h=16564bbdaaaa3fa20c68198903432dfbf7f768a7;hb=HEAD But for the GDB simulator, you can just provide a simple implementation of _exit. In my case, I just defined it as an empty loop, but maybe there's a way to signal the simulator to shut down, I don't know. --- void _exit(int status) { for (;;); } int x = 0; int main(void) { for (int i = 0; i < 1000; i++) { x++; } return 0; } --- Compiled with: $ aarch64-none-elf-gcc test.c -g3 -O0 -o test or $ arm-none-eabi-gcc test.c -g3 -O0 -o test With my arm binary, here's how I can run it with the simulator: $ ./gdb -nx -q --data-directory=data-directory ./test -ex "target sim" -ex "load" -ex "b main" -ex "run" Reading symbols from ./test... Connected to the simulator. Loading section .init, size 0x18 lma 0x8000 Loading section .text, size 0x630 lma 0x8018 Loading section .fini, size 0x18 lma 0x8648 Loading section .rodata, size 0x4 lma 0x8660 Loading section .ARM.exidx, size 0x8 lma 0x8664 Loading section .eh_frame, size 0x4 lma 0x866c Loading section .init_array, size 0x4 lma 0x18670 Loading section .fini_array, size 0x4 lma 0x18674 Loading section .data, size 0x430 lma 0x18678 Start address 0x8128 Transfer rate: 21824 bits in <1 sec. Breakpoint 1 at 0x824c: file test.c, line 10. Starting program: /home/smarchi/build/binutils-gdb-target-arm/gdb/test Breakpoint 1, main () at test.c:10 10 for (int i = 0; i < 1000; i++) { (gdb) n 11 x++; (gdb) 10 for (int i = 0; i < 1000; i++) { I tried to build a GDB for the AArch64 target, but it did not include the simulator. I then did the following change to enable it: diff --git a/gdb/configure.tgt b/gdb/configure.tgt index b3f31af763c..1dcd153f52f 100644 --- a/gdb/configure.tgt +++ b/gdb/configure.tgt @@ -114,6 +114,7 @@ case "${targ}" in aarch64*-*-elf | aarch64*-*-rtems*) # Target: AArch64 embedded system gdb_target_obs="aarch64-newlib-tdep.o" + gdb_sim=../sim/aarch64/libsim.a ;; This got me a GDB for the AArch64 target with simulator support. However, it does not run correctly: $ ./gdb -nx -q --data-directory=data-directory ./test -ex "target sim" -ex "load" -ex "b main" -ex "run" Reading symbols from ./test... Connected to the simulator. Loading section .init, size 0x34 lma 0x400000 Loading section .text, size 0x67c lma 0x400040 Loading section .fini, size 0x34 lma 0x4006bc Loading section .rodata, size 0x58 lma 0x4006f0 Loading section .eh_frame, size 0x4 lma 0x400748 Loading section .init_array, size 0x8 lma 0x410750 Loading section .fini_array, size 0x8 lma 0x410758 Loading section .data, size 0x758 lma 0x410760 Start address 0x400168 Transfer rate: 30016 bits in <1 sec. Breakpoint 1 at 0x4001e8: file test.c, line 10. Starting program: /home/smarchi/build/binutils-gdb-target-aarch64/gdb/test core: 8 byte write to unmapped address 0xfffffff0 at 0x0 Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () I did not push the investigation further. Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-08 16:09 ` Simon Marchi @ 2020-05-08 16:57 ` Joel Sherrill 2020-05-08 17:17 ` Simon Marchi 0 siblings, 1 reply; 12+ messages in thread From: Joel Sherrill @ 2020-05-08 16:57 UTC (permalink / raw) To: Simon Marchi; +Cc: gdb On Fri, May 8, 2020 at 11:09 AM Simon Marchi <simark@simark.ca> wrote: > On 2020-05-08 9:44 a.m., Joel Sherrill wrote: > > Hi > > > > Can someone please provide an example of how to compile a program to run > on > > the aarch64 simulator in gdb? The simple "aarch64-elf main.c -o main" > does > > not link and appears to be missing libgloss type symbols. > > > > I asked on newlib but got no response. I'm hoping someone here knows. > > > > Thanks. > > > > --joel > > RTEMS > > > > Hi Joel, > > If I just compile a "main" function with the bare-metal aarch64 or arm > compiler, it does indeed > complain about a missing _exit function: > > <snip>/gcc/aarch64-none-elf/9.2.1/../../../../aarch64-none-elf/lib/libg.a(lib_a-exit.o): > in function `exit': > <snip>/build/src/newlib-cygwin/newlib/libc/stdlib/exit.c:64: undefined > reference to `_exit' > > I think this is expected, as the runtime requires you to provide some > implementation for _exit, > in other words what you want to do when the program has finished. Maybe > shut down the board, > reset it, shut down the simulator, that's use case-specific. libgloss > indeed provides an > implementation, so I guess you could include that in your program: > > > https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=libgloss/aarch64/_exit.c;h=16564bbdaaaa3fa20c68198903432dfbf7f768a7;hb=HEAD > > But for the GDB simulator, you can just provide a simple implementation of > _exit. In my case, > I just defined it as an empty loop, but maybe there's a way to signal the > simulator to shut > down, I don't know. > On all the elf/eabi targets I have tried over the years, CPU-elf-gcc produced an a.out that was linked with the installed libgloss. I randomly had an sh-elf toolchain laying around and it worked like "sh-elf-gcc m.c" and then both sh-elf-gdb and sh-elf-run could run it on the gdb simulator. The aarch64-elf toolchain installs 4 .specs files from libgloss but adding -specs XXX and trying each with the gdb simulator (via aarch64-elf-run) all fail. home/joel/test-gcc/install-master/aarch64-elf/lib/aem-validation.specs /home/joel/test-gcc/install-master/aarch64-elf/lib/aem-ve.specs /home/joel/test-gcc/install-master/aarch64-elf/lib/nosys.specs /home/joel/test-gcc/install-master/aarch64-elf/lib/rdimon.specs This seems to be an odd case where there is a simulator in the source tree and there is no clear way to use it. Assuming it works. Looks like Nick Clifton added it back in 2015. Surely he had a way to run programs on it. :) > --- > void _exit(int status) > { > for (;;); > } > > int x = 0; > > int main(void) > { > for (int i = 0; i < 1000; i++) { > x++; > } > return 0; > } > --- > > Compiled with: > > $ aarch64-none-elf-gcc test.c -g3 -O0 -o test > > or > > $ arm-none-eabi-gcc test.c -g3 -O0 -o test > > With my arm binary, here's how I can run it with the simulator: > > $ ./gdb -nx -q --data-directory=data-directory ./test -ex "target sim" -ex > "load" -ex "b main" -ex "run" > Reading symbols from ./test... > Connected to the simulator. > Loading section .init, size 0x18 lma 0x8000 > Loading section .text, size 0x630 lma 0x8018 > Loading section .fini, size 0x18 lma 0x8648 > Loading section .rodata, size 0x4 lma 0x8660 > Loading section .ARM.exidx, size 0x8 lma 0x8664 > Loading section .eh_frame, size 0x4 lma 0x866c > Loading section .init_array, size 0x4 lma 0x18670 > Loading section .fini_array, size 0x4 lma 0x18674 > Loading section .data, size 0x430 lma 0x18678 > Start address 0x8128 > Transfer rate: 21824 bits in <1 sec. > Breakpoint 1 at 0x824c: file test.c, line 10. > Starting program: /home/smarchi/build/binutils-gdb-target-arm/gdb/test > > Breakpoint 1, main () at test.c:10 > 10 for (int i = 0; i < 1000; i++) { > (gdb) n > 11 x++; > (gdb) > 10 for (int i = 0; i < 1000; i++) { > > I tried to build a GDB for the AArch64 target, but it did not include the > simulator. I then > did the following change to enable it: > > diff --git a/gdb/configure.tgt b/gdb/configure.tgt > index b3f31af763c..1dcd153f52f 100644 > --- a/gdb/configure.tgt > +++ b/gdb/configure.tgt > @@ -114,6 +114,7 @@ case "${targ}" in > aarch64*-*-elf | aarch64*-*-rtems*) > # Target: AArch64 embedded system > gdb_target_obs="aarch64-newlib-tdep.o" > + gdb_sim=../sim/aarch64/libsim.a > ;; > > This got me a GDB for the AArch64 target with simulator support. However, > it does not > run correctly: > > $ ./gdb -nx -q --data-directory=data-directory ./test -ex "target sim" -ex > "load" -ex "b main" -ex "run" > Reading symbols from ./test... > Connected to the simulator. > Loading section .init, size 0x34 lma 0x400000 > Loading section .text, size 0x67c lma 0x400040 > Loading section .fini, size 0x34 lma 0x4006bc > Loading section .rodata, size 0x58 lma 0x4006f0 > Loading section .eh_frame, size 0x4 lma 0x400748 > Loading section .init_array, size 0x8 lma 0x410750 > Loading section .fini_array, size 0x8 lma 0x410758 > Loading section .data, size 0x758 lma 0x410760 > Start address 0x400168 > Transfer rate: 30016 bits in <1 sec. > Breakpoint 1 at 0x4001e8: file test.c, line 10. > Starting program: /home/smarchi/build/binutils-gdb-target-aarch64/gdb/test > core: 8 byte write to unmapped address 0xfffffff0 at 0x0 > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () > That matches what luck I had on master. I suspect that is a mismatch between the address map of the simulator and whatever the default linker script does. > > I did not push the investigation further. > I think Nick may be the key to getting an answer here. Thanks. --joel > > Simon > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-08 16:57 ` Joel Sherrill @ 2020-05-08 17:17 ` Simon Marchi 2020-05-11 2:35 ` Simon Marchi 2020-05-11 14:26 ` Nick Clifton 0 siblings, 2 replies; 12+ messages in thread From: Simon Marchi @ 2020-05-08 17:17 UTC (permalink / raw) To: joel; +Cc: gdb, Nick Clifton On 2020-05-08 12:57 p.m., Joel Sherrill wrote: > On all the elf/eabi targets I have tried over the years, CPU-elf-gcc produced an a.out that was linked with the installed libgloss. I randomly had an sh-elf toolchain laying around and it worked like "sh-elf-gcc m.c" and then both sh-elf-gdb and sh-elf-run could run it on the gdb simulator. > > The aarch64-elf toolchain installs 4 .specs files from libgloss but adding -specs XXX and trying each with the gdb simulator (via aarch64-elf-run) all fail. > > home/joel/test-gcc/install-master/aarch64-elf/lib/aem-validation.specs > /home/joel/test-gcc/install-master/aarch64-elf/lib/aem-ve.specs > /home/joel/test-gcc/install-master/aarch64-elf/lib/nosys.specs > /home/joel/test-gcc/install-master/aarch64-elf/lib/rdimon.specs Ok, I am not familiar with that. Well, it did work for me to build with: $ aarch64-none-elf-gcc test.c -g3 -O0 -o test -specs=nosys.specs I didn't have to provide my own _exit. According to the DWARF info, the _exit now included in my program comes from: /tmp/dgboter/bbs/rhev-vm1--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/src/newlib-cygwin/libgloss/libnosys/_exit.c > > This seems to be an odd case where there is a simulator in the source tree and there is no clear way to use it. Assuming it works. It's also possible to run it directly like this: $ ./sim/aarch64/run gdb/test core: 8 byte write to unmapped address 0xfffffff0 at 0x0 program stopped with signal 11 (Segmentation fault). The result is the same as when I ran it through GDB. I have no idea if it's the sim that is faulty, or the binary needs to be compiled differently. > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () > > > That matches what luck I had on master. I suspect that is a mismatch between > the address map of the simulator and whatever the default linker script does. Perhaps. With the ARM simulator, when I do "starti" in GDB, I see that it starts executing at the ELF file's entry point. With the AArch64 simulator, it starts at 0 (the entry point of the ELF is not 0). So I also suspect that the initial PC is not right. > > I did not push the investigation further. > > > I think Nick may be the key to getting an answer here. Added him in CC, we'll see :). Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-08 17:17 ` Simon Marchi @ 2020-05-11 2:35 ` Simon Marchi 2020-05-11 14:26 ` Nick Clifton 1 sibling, 0 replies; 12+ messages in thread From: Simon Marchi @ 2020-05-11 2:35 UTC (permalink / raw) To: joel; +Cc: gdb On 2020-05-08 1:17 p.m., Simon Marchi wrote: > It's also possible to run it directly like this: > > $ ./sim/aarch64/run gdb/test > core: 8 byte write to unmapped address 0xfffffff0 at 0x0 > program stopped with signal 11 (Segmentation fault). > > The result is the same as when I ran it through GDB. I have no idea if it's the sim that > is faulty, or the binary needs to be compiled differently. > >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0000000000000000 in ?? () >> >> >> That matches what luck I had on master. I suspect that is a mismatch between >> the address map of the simulator and whatever the default linker script does. > > Perhaps. With the ARM simulator, when I do "starti" in GDB, I see that it starts > executing at the ELF file's entry point. With the AArch64 simulator, it starts > at 0 (the entry point of the ELF is not 0). So I also suspect that the initial > PC is not right. I was wrong here, the PC is fine. I found how to enable traces when running the simulator (not that it's complicated). It crashes after a few instructions: $ ./sim/aarch64/run --trace=on --trace-disasm=on ./sim/aarch64/a.out memory: ERROR: executable is too big: ffffffffffffffff insn: pc = 400168 instr = 58000281 disasm: ldr x1, 0x00000000004001b8 memory: read of 0 (8 bytes) from 4001b8 insn: pc = 40016c instr = 927cec20 disasm: and x0, x1, #0xfffffffffffffff0 insn: pc = 400170 instr = 9100001f disasm: mov sp, x0 insn: pc = 400174 instr = d280001d disasm: mov x29, #0x0 // #0 insn: pc = 400178 instr = a9bf77fd disasm: stp x29, x29, [sp, #-16]! memory: write of 0 (8 bytes) to fffffffffffffff0 core: 8 byte write to unmapped address 0xfffffff0 at 0x0 program stopped with signal 11 (Segmentation fault). What seems to happen is that the code tries to set up the stack pointer, but its initial value read from 0x4001b8 is 0. So it crashes when we try to write to the stack. I have no idea why, I posted this question here: https://sourceware.org/pipermail/newlib/2020/017635.html Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-08 17:17 ` Simon Marchi 2020-05-11 2:35 ` Simon Marchi @ 2020-05-11 14:26 ` Nick Clifton 2020-05-11 14:40 ` Joel Sherrill 1 sibling, 1 reply; 12+ messages in thread From: Nick Clifton @ 2020-05-11 14:26 UTC (permalink / raw) To: Simon Marchi, joel; +Cc: gdb Hi Guys, >> I think Nick may be the key to getting an answer here. > Added him in CC, we'll see :). Gosh - it has been a long time since I played with that simulator. It should work. Or at least it used to work. But maybe things have changed. Would one of you mind doing me a favour though and send me a binary that needs to be simulated ? I no longer have the infrastructure set up for building aarch64 binaries, but in theory that should be no obstacle to simulating them... Cheers Nick ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-11 14:26 ` Nick Clifton @ 2020-05-11 14:40 ` Joel Sherrill 2020-05-11 17:58 ` Jim Wilson 0 siblings, 1 reply; 12+ messages in thread From: Joel Sherrill @ 2020-05-11 14:40 UTC (permalink / raw) To: Nick Clifton; +Cc: Simon Marchi, gdb On Mon, May 11, 2020 at 9:26 AM Nick Clifton <nickc@redhat.com> wrote: > Hi Guys, > >> I think Nick may be the key to getting an answer here. > > Added him in CC, we'll see :). > > Gosh - it has been a long time since I played with that simulator. > > It should work. Or at least it used to work. But maybe things have > changed. > > Would one of you mind doing me a favour though and send me a binary that > needs to be simulated ? I no longer have the infrastructure set up for > building aarch64 binaries, but in theory that should be no obstacle to > simulating them... > I'm trying to build one that will run on the simulator. I haven't managed to do that yet. :( Sorry. --joel > > Cheers > Nick > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-11 14:40 ` Joel Sherrill @ 2020-05-11 17:58 ` Jim Wilson 2020-05-11 18:30 ` Joel Sherrill 0 siblings, 1 reply; 12+ messages in thread From: Jim Wilson @ 2020-05-11 17:58 UTC (permalink / raw) To: joel; +Cc: Nick Clifton, Simon Marchi, gdb On Mon, May 11, 2020 at 7:41 AM Joel Sherrill <joel@rtems.org> wrote: > I'm trying to build one that will run on the simulator. I haven't managed to > do that yet. :( You can find the answer in dejagnu. See baseboards/aarch64-sim.exp which uses -specs=rdimon.specs. The aarch64 gdb sim is incomplete by the way. ARM won't let ARM engineers contribute to it because of IP concerns. I did some work on it when I was at Linaro, but there are still a number of instructions that are missing or implemented wrong. I got the gcc testsuite failures down to about 1200 before I left Linaro. I don't test it anymore, so I don't know the current state. I would suggest using qemu instead unless you want to fix simulator bugs. Jim ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-11 17:58 ` Jim Wilson @ 2020-05-11 18:30 ` Joel Sherrill 2020-05-11 22:13 ` Jim Wilson 0 siblings, 1 reply; 12+ messages in thread From: Joel Sherrill @ 2020-05-11 18:30 UTC (permalink / raw) To: Jim Wilson; +Cc: Nick Clifton, Simon Marchi, gdb On Mon, May 11, 2020 at 12:59 PM Jim Wilson <jimw@sifive.com> wrote: > On Mon, May 11, 2020 at 7:41 AM Joel Sherrill <joel@rtems.org> wrote: > > I'm trying to build one that will run on the simulator. I haven't > managed to > > do that yet. :( > > You can find the answer in dejagnu. See baseboards/aarch64-sim.exp > which uses -specs=rdimon.specs. > > The aarch64 gdb sim is incomplete by the way. ARM won't let ARM > engineers contribute to it because of IP concerns. I did some work on > it when I was at Linaro, but there are still a number of instructions > that are missing or implemented wrong. I got the gcc testsuite > failures down to about 1200 before I left Linaro. I don't test it > anymore, so I don't know the current state. I would suggest using > qemu instead unless you want to fix simulator bugs. > Thanks Jim. That is very helpful. I managed to get an executable to run with aarch64-elf-run and traced it failing quite early at newlib-cygwin/libgloss/aarch64/syscalls.c:287 doing something with the semi-hosting extensions. Have you seen this simulator work well enough recently to run the gcc testsuite? It sounds like for my purposes of where to start development of an aarch64 RTEMS port, this is one time we need to skip the gdb simulator step. The gdb simulators are just so nice to work through basic issues like context switching, stack setup, etc. Since we would only need C with basic integer operations and enough FPU support to context switch the FPU, 1200 gcc failures may not have been a stopper. I know that it has limited use since there are so many alternatives and embedded folks are just going to use CMSIS or some OS support. I was just hoping to use it to add to the free RTOS list. Guess we will start with Qemu unless someone has some brilliant idea that makes this work. Thanks again Jim. --joel > > Jim > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-11 18:30 ` Joel Sherrill @ 2020-05-11 22:13 ` Jim Wilson 0 siblings, 0 replies; 12+ messages in thread From: Jim Wilson @ 2020-05-11 22:13 UTC (permalink / raw) To: joel; +Cc: Nick Clifton, Simon Marchi, gdb On Mon, May 11, 2020 at 11:30 AM Joel Sherrill <joel@rtems.org> wrote: > Thanks Jim. That is very helpful. I managed to get an executable > to run with aarch64-elf-run and traced it failing quite early at > newlib-cygwin/libgloss/aarch64/syscalls.c:287 doing something with > the semi-hosting extensions. Have you seen this simulator work > well enough recently to run the gcc testsuite? It has been maybe 2.5 years since I last tried. That is about when I left Linaro. > It sounds like for my purposes of where to start development of an > aarch64 RTEMS port, this is one time we need to skip the gdb simulator > step. The gdb simulators are just so nice to work through basic issues > like context switching, stack setup, etc. Since we would only need C > with basic integer operations and enough FPU support to context > switch the FPU, 1200 gcc failures may not have been a stopper. I don't know if any of the system instructions work. A gcc testsuite run will only test user instructions. I like the gdb simulators too. That is why I did some work with it. Jim ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-08 13:44 Running programs on aarch64 simulator Joel Sherrill 2020-05-08 16:09 ` Simon Marchi @ 2020-05-08 16:16 ` Luis Machado 2020-05-08 16:44 ` Joel Sherrill 1 sibling, 1 reply; 12+ messages in thread From: Luis Machado @ 2020-05-08 16:16 UTC (permalink / raw) To: joel, gdb On 5/8/20 10:44 AM, Joel Sherrill wrote: > Hi > > Can someone please provide an example of how to compile a program to run on > the aarch64 simulator in gdb? The simple "aarch64-elf main.c -o main" does > not link and appears to be missing libgloss type symbols. > > I asked on newlib but got no response. I'm hoping someone here knows. > > Thanks. > > --joel > RTEMS > Would QEMU be a better option to exercise some bare-metal programs? The GDB simulator has not been receiving a lot of maintenance. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Running programs on aarch64 simulator 2020-05-08 16:16 ` Luis Machado @ 2020-05-08 16:44 ` Joel Sherrill 0 siblings, 0 replies; 12+ messages in thread From: Joel Sherrill @ 2020-05-08 16:44 UTC (permalink / raw) To: Luis Machado; +Cc: gdb On Fri, May 8, 2020 at 11:16 AM Luis Machado <luis.machado@linaro.org> wrote: > On 5/8/20 10:44 AM, Joel Sherrill wrote: > > Hi > > > > Can someone please provide an example of how to compile a program to run > on > > the aarch64 simulator in gdb? The simple "aarch64-elf main.c -o main" > does > > not link and appears to be missing libgloss type symbols. > > > > I asked on newlib but got no response. I'm hoping someone here knows. > > > > Thanks. > > > > --joel > > RTEMS > > > > Would QEMU be a better option to exercise some bare-metal programs? The > GDB simulator has not been receiving a lot of maintenance. > Long term it is a better option but the gdb simulators have proven more than sufficient to work through the basic issues of an RTEMS port and they are quite simple to use. You can get initialization, context switch, etc. Definitely have to move to Qemu to get interrupts worked out and real device drivers. --joel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-05-11 22:13 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-08 13:44 Running programs on aarch64 simulator Joel Sherrill 2020-05-08 16:09 ` Simon Marchi 2020-05-08 16:57 ` Joel Sherrill 2020-05-08 17:17 ` Simon Marchi 2020-05-11 2:35 ` Simon Marchi 2020-05-11 14:26 ` Nick Clifton 2020-05-11 14:40 ` Joel Sherrill 2020-05-11 17:58 ` Jim Wilson 2020-05-11 18:30 ` Joel Sherrill 2020-05-11 22:13 ` Jim Wilson 2020-05-08 16:16 ` Luis Machado 2020-05-08 16:44 ` Joel Sherrill
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).