On 15/06/2023 21:51, René Ferdinand Rivera Morell wrote:
> On Thu, Jun 15, 2023 at 3:16 PM Stephen Kelly <steveire_at_[hidden]> wrote:
>>
>> I have seen the suggestion of a command line option, and the option of a file next to the tool, but I haven't seen a suggestion of what Qt does for the last 11 years for plugin loading, which has many of the same challenges with cross-compiling etc. That is - embed the metadata into the binary itself and read the data from a readonly section of the binary:
>>
>> $ objcopy /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqtiff.so /dev/null --dump-section .qtmetadata=/dev/stdout
>> QTMETADATA !�x1org.qt-project.Qt.QImageIOHandlerFactoryInterfacekQTiffPlugin�dKeys�dtiffctifiMimeTypes�jimage/tiffjimage/tiff
>>
>>
>> I think in Qt 6 it works the same way, but the plugins have cbor data encoded in them. This allows Qt to know whether a plugin can load .jpg or .png etc.
>>
>> https://lists.qt-project.org/pipermail/development/2012-February/001827.html
>>
>> You could try to pursue something similar, but it would assume/require a way to read data sections from a binary.
> That's an interesting approach. Does that mean you would need
> different methods to get the data based on the environment?


Different methods based on the file. I guess that's what you mean by
environment. ie, if you have an elf file, you need some tool (or C++
API/other language API/custom parser for the binary format) which can
understand elf, regardless of the platform you are running on.

Qt doesn't operate on all of the platforms that are relevant for C++,
but it has ways to extract the data from ELF, PE/COFF and Mach-O files.
It also has a "slow fallback" where it just searches for a magic string
followed by the data. See qlibrary.cpp if you can just look at Qt code
to see how it's done in code.

The things that I think could kill this idea are

1) Requiring a different way to access the metadata per binary format

2) The binary format needing a way to have the metadata retrievable
within it without affecting the running of the binary.

I have no idea whether either is a real problem.

> And how do
> those methods work if the binary is for another environment?


In the case of Qt, the ELF files are only loaded on an elf platform, but
(I assume) there is no reason you can't have an ELF parser on Windows or
a PE/COFF parser on Linux?

It would also be possible to have a proof of concept tool written in
some widely available language which abstracts those differences in
binary format away (for known platforms) and dumps the json/cbor data.


> Something else that a friend brought up is that the introspection
> information may depend on environment information that is only
> available at install time. I.e. that it can't be fixed data.


I think D2717 so far only has spec for outputting the versions of
metadata, so I'm not sure what it could contain that would be dependent
on environment variables. Do you have an example?

I guess a compiler which can be used as a cross-compiler (clang or QNX
QCC) could have different capabilities (availability of thread_local or
C++26, for example) depending on what it is targetting, but I'm sure
there's some way of expressing that statically.

Thanks,

Stephen.