Boost logo

Boost :

From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-09-12 13:57:27


11 septembre 2024 à 21:46 "Дмитрий Архипов via Boost" <boost_at_[hidden]> a écrit:

> Recently Niall Douglas posted about his idea to embed GDB pretty
> printers into binaries using a header. At the time I was thinking
> about a good way to deploy pretty printers for JSON that facilitates
> their autoloading. After Niall's post I experimented a little bit
> more, and I came to the conclusion that indeed nothing beats embedding
> via a C++ header in terms of convenience.

I mostly agree with that statement, with a few caveats though. The main
issue i've seen is that with some linkers, the .debug_gdb_scripts section
is duplicated several times when the file is included several (although not
exactly once per inclusion…), and this causes issues later with gdb (types
registering multiple times, etc.).

While i observed these only with compilers for embedded targets and pretty
old toolchains, we finally used a different approach, based on the inclusion
of a single cpp file in the project. This is not feasible for boost, however,
i think the following can be done quite easily:

* the macro to opt out from gdb pretty printing already exists, move its
  usage from inside gdb_printers.hpp to config.hpp
* provide a public (ie, not in details) json/debug_printers.hpp file, which
  unconditionnaly includes gdb_printers.hpp, to opt-in again. This file
  shall not be included by any library code.

This allows client code to circumvent the limitations, and is fully transparent
for users not affected by the duplicated python code issue.

I can file a PR if you are ok with this approach.

> My questions to the community: do you find this useful? Would you use
> it in your Boost or non-Boost library? If you do, the module should be
> moved to tools rather than stay in libs/json.

Testing printers is indeed part of the job (we've had our bunch of broken
printers where i work), so yes, this is definitely useful. Thanks for sharing
this.

Regards,

Julien


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk