Documentation | Draft: Add section "Debugging" to RTEMS documentation (!43)

Christian Mauderer (@c-mauderer) gitlab at rtems.org
Sun Aug 18 13:59:35 UTC 2024



Merge request https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/43 was reviewed by Christian Mauderer

--
  
Christian Mauderer started a new discussion on user/debugging/.vscode/settings.json: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/43#note_111213

 > +    "html.format.wrapLineLength": 80,
 > +    "rewrap.autoWrap.enabled": true
 > +}

Please don't add editor-specific configurations.

--
  
Christian Mauderer started a new discussion on user/debugging/gdb.rst: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/43#note_111214

 > +To add support for auto-loading pretty-printing scripts for GDB in RTEMS, a
 > +small section containing a Python script is added to all executable files. This
 > +section is responsible for registering the pretty-printers provided by GCC & all

Is there some reason for the `&` or is it just meant as an `and`? I'm not a native speaker so maybe it's quite common to write it like that. But it's something I would need a moment to think about while reading. From my point of view, that's usually not good for a manual.

--
  
Christian Mauderer started a new discussion on user/debugging/gdb.rst: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/43#note_111215

 > +        use it at your own discretion and only load trusted executables in GDB.
 > +
 > +#. *Short term*

I think I would move the *Short term* to the first point and call it *Suggested safe method*. Instead of *Long term* I would use *Lazy unsafe method*. Just to make it clear that the RTEMS project is not recommending the unsafe method.

--
  
Christian Mauderer started a new discussion on user/debugging/gdb.rst: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/43#note_111216

 > +
 > +        (gdb) load
 > +        (gdb) b main

Are you sure, you want to use the short form ``b`` instead of the long (but better readable) ``break``?

--
  
Christian Mauderer started a new discussion on user/debugging/gdb.rst: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/43#note_111217

 > +
 > +OpenOCD is a JTAG debugging package that interfaces to a wide of JTAG pods. JTAG
 > +is a low level high speed serial interface modern processors provide as a means

Maybe it's because I'm not a native speaker but somehow that sentence feels odd. Shouldn't it be something like
```
... low level high speed serial interface provided by modern processors as a means ...
```
Beneath that: I think I would use ``most`` instead of ``modern``. I don't think I have seen much processors that don't provide a JTAG (or a derived version of it).

--
  
Christian Mauderer started a new discussion on user/debugging/gdb.rst: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/43#note_111218

 > +
 > +Debugging with GDB & QEMU
 > +-------------

More general note regarding that chapter: I think it's partially copied from ``10.6 Debugging`` of the current manual, right? If yes: Can you please remove the sections that are replaced by that? I don't like having the same information twice in a manual. Beneath that, it's possible that ``git`` detects that and marks the text as moved instead of added.

--
  
Christian Mauderer started a new discussion on user/debugging/index.rst: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/43#note_111219

 > +
 > +#. Set breakpoints to pause execution at specific points
 > +

Do you need the empty lines? Has it side-effects like starting a new enumeration after each empty line?




-- 
View it on GitLab: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/43
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/20240818/5e24dd14/attachment-0001.htm>


More information about the bugs mailing list