[libc-commits] [libc] [llvm] [libc] Move generated elf header to include (PR #211428)

[Pavel Labath via libc-commits]

================
@@ -1,667 +1,5 @@
 header: elf.h
+public_includes:
----------------
labath wrote:

Thanks for the explanation. Let me try to elaborate on my comment as well.

My issue isn't about the style of includes. It's about the existence of this file (at this path). Eventually, elf.h will get installed to `/usr/include/elf.h`. Now, regardless of how it includes the proxy, if we want user code doing `#include <elf.h>` to work, we will also need to install the proxy to `/usr/include/proxy/elf_proxy.h`. I think this path is unfortunate, because it doesn't indicate that:
- it is a part of llvm libc
- it is not meant to be included directly (it looks like a header of some network ELF execution library :P)

Our other private headers go into `/usr/include/llvm-libc-{types,macros}`, which don't have these two problems. So I think we should at least call this something like `llvm-libc-proxies/elf_proxy.h`.

That said, I'm still not sure as to what is special about elf.h, that it needs this infrastructure. IIUC, the problem here is that we have some code (the startup routines?) which needs to access constants defined in elf.h without an `#include <elf.h>`. This is something we don't have a good answer to, but it's not a problem unique to elf.h. I ran into this in the socket code, and the advice I was given was to move the definitions to `xxx-macros.h`, and I think that should work here too. It's not an ideal solution, but neither is having two ways to do this kind of thing.

However, I also think I'm getting out of my depth here, so I don't want to block this patch on that.

https://github.com/llvm/llvm-project/pull/211428