<div dir="ltr"><div>Recently, there was a discussion (<a href="http://lists.llvm.org/pipermail/llvm-dev/2019-July/133648.html">http://lists.llvm.org/pipermail/llvm-dev/2019-July/133648.html</a>) about build dependency on Python and the conclusion of that thread is that it's something we want to avoid.</div><div><br></div><div>Since the standard_api.py script is used for generating code (headers and source), could we possibly use tablegen for that purpose (and describe the API surface in a .td file)?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 8, 2019 at 2:23 PM Siva Chandra via libc-dev <<a href="mailto:libc-dev@lists.llvm.org">libc-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
In the source tree, we have different items like header files,<br>
implementation .cpp file etc, which have to conform to the public API<br>
specified by various standards. Currently, the header files and<br>
implementation files are prepared in a disjointed fashion. That is, we<br>
write them manually and separately. There is no check to verify that<br>
these separate entities are coherent and that they are conforming to<br>
the standard. So, I propose fixing this using a ground truth file.<br>
Other files are either generated using the information found in this<br>
ground truth file, or are checked against this ground truth file. The<br>
different parts of this proposal are as follows:<br>
<br>
1. Ground truth file syntax: There will be a single ground truth file<br>
for the entire public API surface of the libc. This file will be human<br>
and machine editable. I propose that it be a Python file named<br>
standard_api.py defining a dictionary in the following manner:<br>
<br>
API = {<br>
    <header file>: {<br>
        <func name>: {<br>
            "return_type": <return type>,<br>
            "args": [<arg list>],<br>
        }<br>
        ...<br>
    }<br>
    ...<br>
}<br>
<br>
2. Generating all public headers: The current code has a few examples<br>
of generating header files. I propose that we generate all public<br>
header files using the information found in standard_api.py. This<br>
requires the addition of a new command to the header configuration<br>
language. Specifically, I propose adding a command named %%func. The<br>
usage of this command can be illustrated with the example of the round<br>
function:<br>
<br>
    // math.h.def<br>
    ...<br>
    %%func(round)<br>
    ...<br>
<br>
The header generator will replace the line on which the %%func command<br>
is listed with the declaration of the round function as specified in<br>
standard_api.py.<br>
<br>
3. Entrypoint wrappers: The current way of adding a C symbol via a<br>
post processing step might not be feasible on all targets. For<br>
example: <a href="http://lists.llvm.org/pipermail/libc-dev/2019-October/000000.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/libc-dev/2019-October/000000.html</a>.<br>
For such targets, I propose that we generate a C wrapper for the C++<br>
implementation as part of the add_entrypoint_obj rule. Availability of<br>
the ground truth file facilitates the generation of these wrappers in<br>
a straightforward manner. The wrappers also help in the use case of<br>
LTO across app + libc. Moreover, since the wrappers are generated from<br>
the ground truth, their successful compilation ensures that the<br>
implementation conforms to the ground truth.<br>
<br>
WDYT?<br>
<br>
Thanks,<br>
Siva Chandra<br>
_______________________________________________<br>
libc-dev mailing list<br>
<a href="mailto:libc-dev@lists.llvm.org" target="_blank">libc-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libc-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libc-dev</a><br>
</blockquote></div></div>