[libc-dev] Platform and architecture abstraction layers

[Siva Chandra via libc-dev]

On Tue, Mar 31, 2020 at 7:42 AM David Chisnall via libc-dev <
libc-dev at lists.llvm.org> wrote:

> Hello libc people,
>
> When llvm-libc was approved for incorporation into LLVM, the stated goal
> was to provide a portable libc implementation.  I'm quite concerned that
> we are increasingly seeing a load of Linux-specific code being
> committed.

This is all in a linux directory, which is fine in theory,
> but I don't want us to end up with an entire libc in linux/x86-64/* and
> nothing elsewhere.  It is much easier to build portable software from
> the start than it is to retrofit portability.  We need to start putting
> in platform and architecture abstraction layers from the start.
>

I totally agree. We have to start somewhere, and we have started with
x86_64 on linux as that is the most easily accessible platform for us
working on libc. As the structure gets more complicated, and as we start
adding more architectures (which we will), we will definitely pull out the
common code and build abstraction layers. The memcpy implementation already
has a small example of abstraction (may be trivial at this point) for
handling i386 and x86_64.

Most of the code committed in linux/x86_64/start.cpp, is either
> identical or almost identical on all architectures and all System-V ABI
> platforms.  As the code is currently structured, this is going to be
> copied and pasted repeatedly.
>

The same points as above hold for this as well. But, I take your point and
do understand what you are saying. FWIW, no one wants copy-pasted code. As
I said above, we have to start somewhere and this is where we started.

Few observations which are probably not related to the topic of this thread:
>From my side personally, I have been very particular with getting the code
structure right in my own patches as well when doing code reviews. At the
same time, I also do not want the quest for perfection to hinder progress.
A nice side effect of allowing progress is that it allows us to learn. And,
there have been a few instances wherein we reversed our initial decisions
as we realized they were not good enough. Also, for a project as vast as a
libc, trying and experimenting should be encouraged even if not all of them
succeed (personally, I am OK if most of them fail as long as they teach us
something.)

Thanks,
Siva Chandra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libc-dev/attachments/20200401/caca4df9/attachment.html>