Dear Dr. Bloom, Thank you for your suggestions. Yes, I realized after your mail that different architecture would have different assembly code, which I was not aware of and assumed every .S file has the same rules.
I will set up an appropriate environment as you both suggested. Thanks. On Fri, May 29, 2020 at 8:34 PM Gedare Bloom <ged...@rtems.org> wrote: > > On Fri, May 29, 2020 at 1:59 AM Richi Dubey <richidu...@gmail.com> wrote: > > > > This makes sense. Thanks a lot! > > > > > > On Fri, May 29, 2020 at 1:18 PM Sebastian Huber > > <sebastian.hu...@embedded-brains.de> wrote: > > > > > > Hello Richi, > > > > > > On 29/05/2020 09:36, Richi Dubey wrote: > > > > Hii, > > > > > > > > I had a small doubt about all the source code/procedures that a code > > > > goes through. Where can I read more about it? For instance, when I am > > > > debugging smpschededf02.exe with gdb, It starts with > > > > bsps/sparc/shared/start/start.S, line 107(Why did it start with > > > > start.s?) and the last line of this file is: > > > > > > > > mov %g0, %o0 ! command line > > > > call SYM(boot_card) ! does not return > > > > sub %sp, 0x60, %sp ! room for boot_card to save > > > > args > > > > > > > > After this it starts executing bsps/shared/start/bootcard.c: line 53 . > > > > How did this happen? Is it because of call? If yes, why was sub > > > > executed(in gdb) before executing code from bootcard.c? > > > > > > > > I hope I am not trying to going too deep into this. I just want to > > > > have a overall picture of how a code gets executed. > > > > > > if you want to learn how code executes at processor level, then I would > > > recommend to work with an ARM (Qemu) or RISC-V (SIS, Qemu) simulator. > > > These are the currently most relevant architectures. SPARC is a dead > > > architecture and it has some peculiarities which were a nice idea in the > > > 1980s. > > > > > > > This is necessary > > > > for writing your own code in RTEMS, right? > > > It helps, but it is not necessary. > +1 > > This is quirky assembly stuff. Your project should not require writing > assembly, but it is helpful if you can start to learn how to read it > for debugging. > > If you know a different assembly language, you might try to set up an > environment with that target and use it for low-level debugging > purposes. Mostly though, gdb should take care of translating the > executing lines to source linkage, so you would only face trouble when > debugging assembly source like this. As Sebastian mentioned, if you > don't know an assembly language, your time is better spent to learn a > modern widely used one. > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
