2017-06-07 22:41 GMT+03:00 Hesham Almatary <heshamelmat...@gmail.com>:
> On Thu, Jun 8, 2017 at 2:26 AM, Denis Obrezkov <denisobrez...@gmail.com> > wrote: > > 2017-06-07 14:44 GMT+03:00 Sebastian Huber > > <sebastian.hu...@embedded-brains.de>: > >> > >> On 06/06/17 18:58, Hesham Almatary wrote: > >> > >>> Originally RTEMS had a one big linkcmd for each platform, which > >>> defines linker symbols (used in C code) and required sections. This > >>> has been improved with current BSPs (like ARM-based ones), by > >>> splitting up shared linkcmd parts (linkcmd base) and BSP specific ones > >>> that include the shared one. riscv_generic, given that it's old, > >>> follows the old way of having a single big linkcmd. You can change > >>> this for your new BSP. > >> > >> > >> New ports/BSPs should definitely use a shared linkcmds.base (see ARM). > Use > >> "riscv-rtems4.12-ld --verbose" to get the default linker script. > > > > Ok. > > > > Now I have a problem: > > https://github.com/embeddedden/rtems-riscv/blob/ > hifive1/c/src/lib/libbsp/riscv32/hifive1/start/start.S#L117 > > When I step to that line, gdb hangs with a message: > > (gdb) step > > Note: automatically using hardware breakpoints for read-only addresses. > > > How do you run/attach simulator (and which one do you use)? Do GDB and > the simulator support 0x20400000 > addresses (where your text section > is loaded to)? AFAIK, that's not the case. Spike's default machine > only works with addresses >= 0x80000000. You've to look up if Spike, > Qemu [1] or GDB target sim model your board. > I will investigate this. Could you also explain you .stack section in linkcmd file? is it on purpose always of zero size (.work section consumes all remaining memory)? -- Regards, Denis Obrezkov
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel