Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of wrong function signatures (mainly signedness) for standard C functions #98

Open
hikari-no-yume opened this issue Apr 22, 2021 · 5 comments

Comments

@hikari-no-yume
Copy link
Collaborator

Both GCC and Clang don't like it when you redeclare functions from the standard library with the wrong types. The main way LLVM-CBE does this is by getting the signedness wrong, because of course LLVM doesn't have signedness in types. (I don't know if there's other ways the types are wrong, but it seems likely.) For both compilers, the warning prompted by these redeclarations can be silenced, but ideally we'd avoid the warning in the first place.

There's a similar thing going on with main, which is a bit more annoying because that's an error by default, rather than a warning. We do of course silence that error also, but it would be nice not to have to.

I am willing to invest a bit of time to try to fix this, at least for common cases.

For main, I think the best thing to do is just to special-case it. It is after all a special case! We can use the correct signature for it, and maybe add casts in the body.

For standard library functions, some possibilities are:

  • Don't re-declare standard library functions. But in order to do this, we'd need an accurate list of standard library functions. That sounds troublesome.
  • Don't include standard library headers at all. But would that be safe or correct? Does the C standard let us do this? If it does work, it relies on ABI luck…

I suppose a vaguely similar problem can exist for linking against normal C code as well. But arguably we don't need to care so much about that, because you can just write your own wrapper that provides LLVM-CBE-friendly types.

@vtjnash
Copy link
Member

vtjnash commented Apr 22, 2021

We do import some headers, as required for platform-specific definitions like alloca, but try to avoid it typically. The output is typically not ABI-compatible with the original C code (since the target machine is wrong) anyways and it seemed to lead to an ever-growing number of conflicting definitions. It seems like a good idea to special-case main though.

(Aside: it is not entirely true that LLVM doesn't have signedness: the CBackend should print with the correct signedness if it mattered for the original platform ABI that was targeted.)

@vtjnash
Copy link
Member

vtjnash commented Apr 22, 2021

Hm, since the issue is a clang::TargetInfo information mismatch, many of those issues perhaps actually could be fixed by writing a "CBackendTargetInfo" for libClang, which was pretty basic and just made sure every argument was tagged with signedness and avoided argument ABI mangling. Perhaps based on something similarly simple and high-level like WebAssembly?

@hikari-no-yume
Copy link
Collaborator Author

I guess you'd have to do something similar for any other language frontend you want to get good code for when combined with LLVM-CBE.

@vtjnash
Copy link
Member

vtjnash commented Apr 22, 2021

Yes, but probably they'd usually be pretty simple to create. Mostly it is about disabling features of the frontend, so that it passes through the data verbatim. For example, I work on the Julia frontend, for which the relevant definitions file would be https://github.com/JuliaLang/julia/blob/master/src/abi_llvm.cpp

@hikari-no-yume
Copy link
Collaborator Author

I didn't realise it until now, but trying to avoid redefining standard library functions is probably what this code is for:

https://github.com/JuliaComputingOSS/llvm-cbe/blob/a58340edfbf8464f253b2921a51fdd7d7f19990b/lib/Target/CBackend/CBackend.cpp#L2495-L2507

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants