RTEMS | GDB Auto-loading of Python (&1)
Suraj Kumar (@the.m3chanic)
gitlab at rtems.org
Sun Jul 7 18:35:50 UTC 2024
Suraj Kumar commented: https://gitlab.rtems.org/groups/rtems/-/epics/1#note_108823
I am posting all my updates so far as comments here as per gedare's suggestion
Week 1:
```
Planned:
[+] Set up blog website for writing weekly blogs for GSoC
[+] Learn about basic kernel structures (mainly semaphores & task control blocks)
[+] Set up a debugging environment for testing out C++ applications via GDB
[+] Go through my host GDB installation vs RTEMS' GDB installation to identify differences, then look at existing pretty printing scripts (including the ones Chris had linked for me when I was writing my proposal)
Done:
[+] Set up blog successfully ✅
[+] Learned about semaphores, I'm reading from a book so I also ended up delving deeper into other OS related things apart from just structures, to get a better general idea overall
[+] Set up a debugging environment, and tested GDB on various C++ programs implementing different STL objects, across different BSPs on various architectures (namely arm/xilinx_zynq_a9_qemu, x86_64/amd64, sparc/leon3) ✅
[+] Went through the basic files present in both, kind of got lost in trying to understand the context of various files in there - spent some time on that. Also looked at existing pretty printing implementations and tried to get a side-by-side view on C++ STL objects that I write vs the implementation and how they're handled by the pretty-printer.
Blockers:
[-] Not too many, except I was travelling from home to college midway so lost about 1.5 days on that
```
Week 2:
```
Planned:
- Design initialisation hook to run GDB commands for specific installation prefixes on GDB, which run every time GDB is loaded
- Continue learning about Task Control Blocks
Done:
- Have good progress on various ways in which I can design the initialisation hook (narrowed it down to 3 methods - 2 sub-par and 1 ideal) [`~/.gdbinit`, `-x init.gdb`, `auto-load` directory]
- Learned more about Task Control Blocks and Process Environment Blocks and how PEB's work (sources: https://pages.cs.wisc.edu/~remzi/OSTEP/, https://ia801902.us.archive.org/28/items/operating-system-concepts-10th/operating-system-concepts-10th.pdf)
Blockers:
- Got sick, so couldn't work for about a day and a half in between
Planned for next week:
- Finish designing the initialisation hook on GDB
- Look into setting up a kernel debugging environment on RTEMS
```
Week 3:
```
Planned:
- Get auto-loading + pretty-printing to work
- Look into setting up kernel debugging environment (i sort of pushed this back a bit to focus more on the init-hook, will work on it in the upcoming weeks)
Done:
- Finalised on .debug_gdb_scripts approach to adding initialisation hook, and got auto-loading + pretty-printing to work perfectly, working on different approaches to handle exception it causes (should be easy)
- Looking into adding config flag when building GDB from source to add system-wide gdbinit directory
- Modifying linkercmd script to add custom section to script without "section outside of ELF segment warning"
Blockers:
-
Planned for the coming week:
- Modify linkercmd script to add section to ELF when building app for one BSP, then implement the same to every BSP
- Figure out way to keep track of path to said initialisation script
- (possibly) explore option of modifying config options when building GDB to test "{prefix}/usr/share/gdb/system-gdbinit" as the system-wide init directory
```
Week 4:
```
Planned:
- Modify linkercmd script to add section to ELF when building app for one BSP, then implement the same to every BSP
- Figure out way to keep track of path to said initialisation script
- Explore option of modifying config options when building GDB to test "{prefix}/usr/share/gdb/system-gdbinit" as the system-wide init directory
- Get at least auto-loading to work along with linker modifications
Done:
- Successfully did linkercmd.base modifications and got pretty-printing to work, although, hit roadblock when finding ways to keep track of path to pretty-printing script
- Got config option modification to work, but ruled it out for non-optimal design
- Went back and forth with GDB devs regarding possible solutions for issue, then discovered that there is no solid one at the moment
- Discovered new way of loading script (embedding script text inside section). Tested it, and it works well without any need of maintaining paths. Currently working with mentors to try and finalise on one approach
Blockers:
- Very little/no documentation for the problem i am trying to fix, so finding ways that work + will be sustainable on RTEMS is quite challenging
Planned for next week:
- Work with mentors & hopefully finalise on approach. Currently i'm not too sure what I can plan ahead to make my work optimal
```
Week 5:
```
Planned:
[Was a bit shaky at first, i.e, was not sure what to do], nevertheless
- Go through implementations of workarounds to the current problem (those by Rust and AdaCore)
- Understand the dependencies of both implementations, and weigh their pros and cons
- Work together with mentors on the current approaches I have, and get on the same page as them
- Discuss with Rust & AdaCore users on their workarounds to the current problems, to get a better insight
Done:
- Researched about Rust's wrapper, and found most of its pros and cons (from [here](https://github.com/rust-lang/rust/commits/master/src/etc/rust-gdb), we can see that it was modified only once in the last 10 years due to an arg conflict, rest were quality-of-life improvements)
- Decided not to go ahead with Rust's solution due to lack of benefits and conflicting design choices
- Worked with mentors and finalised an approach (adding Python script to .debug_gdb_scripts section)
- Looked into using linker command scripts to modify section content at compile/linking time without modifying script source (reading from here: https://users.informatik.haw-hamburg.de/~krabat/FH-Labor/gnupro/5_GNUPro_Utilities/c_Using_LD/ldLinker_scripts.html#Output_section_data)
Blockers:
- Lack of resources/discussions from previous people struggling with the same problem
Planned:
- Find out way to reference pre-installed GCC files from embedded script without external dependencies
- Find out reliable method to modify output section content through linker command files (or something under the hood, not involving the user)
```
Week 6:
```
[Update is only for work since this Monday, and Wednesday-Thursday 2 weeks back]
Planned:
1. Write stdcxx.py to register pretty-printers after finding path to GCC
2. Modify linkcmds to add custom section to ELF every time when compiling
2. Start work on RSB to figure out GCC version dynamically (at build time)
Done:
1. Wrote stdcxx.py
2. Modified linkcmds.base
3. Working on RSB detailing to find GCC version
4. Drafting MRs for adding stdcxx.py as well as linkcmds.base modifications for ARM, currently building from source and testing
Blockers:
None
Planned for coming week:
1. Merge both MRs
2. Finalise RSB detailings to identify GCC version(s)
3. Test this feature on various BSPS/architectures to identify which platforms it works on and how I can identify it
```
Week 7:
```
Planned:
1. Merge both MRs [this got corrected to just one MR, which is a WIP currently]
2. Finalise RSB detailings to identify GCC version(s)
3. Test this feature on various BSPS/architectures to identify which platforms it works on and how I can identify it
Done:
1. Tested feature across following architectures/BSPs:
a. aarch64/raspberrypi4b - 64-bit LSB
b. bfin/eZKit533 - 32-bit LSB
c. powerpc/qemuppc - 32-bit MSB
d. sparc/leon3 - 32-bit MSB
e. sparc64/niagara - 64-bit MSB (relaxed memory ordering)
f. x86_64/amd64 - 64-bit LSB
g. i386/pc386 - 32-bit LSB
h. riscv/mpfs64imafdc - 64-bit LSB
i. x86_64/amd64 - 64-bit LSB
j. arm/xilinx_zynq_a9_qemu - 32-bit LSB
k. sh/simsh4 - 32-bit LSB
l. or1k/generic_or1k - 32-bit MSB
m. v850/v850e2v3sim - 32-bit LSB
n. nios2/nios2_iss - 32-bit LSB
o. moxie/moxiesim - 32-bit MSB
2. Identified parts of RSB scripts to work on to retrieve GCC Version info, and came up with a few ideas to incorporate into script
3. Started making final commits to the MR to modify linker scripts for every architecture (https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/98), remaining linker scripts are under-way, following which commit for modification to cpukit/sapi/src/exinit.c is ready but waiting for linker mods first
Blockers:
Spent almost a day's worth of time building/fixing LLVM & Python version update issues
Planned for coming week:
1. MR with changes to RSB script (gcc-common-1.cfg)
2. Merge MR which will add section to ELFs
3. Modify documentation mentioning to add line (`set auto-load safe-path /`) to ~/.gdbinit. [I am not yet sure where this addition would come, but think it would be necessary because users will try and load their executable into GDB and get an error about the inlined script not being inside auto-load safe-path]
```
--
View it on GitLab: https://gitlab.rtems.org/groups/rtems/-/epics/1#note_108823
You're receiving this email because of your account on gitlab.rtems.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240707/9863fc69/attachment-0001.htm>
More information about the bugs
mailing list