RTEMS | Draft: Add new section: .debug_gdb_scripts, across all executables on RTEMS (!98)

[Chris Johns (@chris)]

Chris Johns commented on a discussion on cpukit/sapi/src/exinit.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/98#note_109356

 >  
 > +/* 
 > + * Additional Macro to add custom section (.debug_gdb_scripts) to 
 > + * every ELF being built on RTEMS, in order to add auto-loading 
 > + * support for Python scripts (specifically, GCC's pretty-printing
 > + * scripts), by in-lining the Python script in the section.
 > + */
 > +#define DEFINE_GDB_PY() \
 > +  asm( \
 > +    ".pushsection \".debug_gdb_scripts\", \"MS\", at progbits,1\n" \
 > +    ".byte 4\n" \
 > +    ".ascii \"gdb.inlined-script\\n\"\n" \
 > +    ".ascii \"import sys\\n\"\n" \
 > +    ".ascii \"import os.path\\n\"\n" \
 > +    ".ascii \"sys.path.append(os.path.join(gdb.PYTHONDIR, 'rtems'))\\n\"\n" \
 > +    ".ascii \"import rtems.stdcxx as stdcxx\\n\"\n" \

The idea was to minimize the amount of code we add here and to align the contents of `stdcxx.py` with what ever GCC does. Adding the needed code here means this code is then keyed into how GCC lays out out the pretty printers.

How would find the version string for GCC? I cannot find it in the built in defines? The `stdcxx.py` is updated by the RSB when installing `gcc` to point to the specific release of `gcc` being built. The RSB finds the version by running the freshly built `gcc`.

Being in `rtems-tools` we cpuld use it to handle RTEMS specific pretty printers as well. I suppose in respect to that maybe the file should be called `rtems.pprinters` and it loads `stdcxx.py`?

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/98#note_109356
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/20240716/e61cad63/attachment-0001.htm>