> On Jun 27, 2019, at 2:53 PM, Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > So, what do you think about incorporating this new libc under the LLVM project? > > As stated, I really feel that this is far too specialised to certain use cases that are pertinent to Google. I think that this needs to be broadened to allow a general purpose libc much as libc++ is a general C++ implementation. I think that the project has a different set of requirements and seems like it would be extremely interesting to see how it would develop over time. This could really be an interesting choice for a certain type of project but as described feels like it is best explored outside of the umbrella of LLVM. >I don't have a strong stake in this decision, but Saleem's commentary matches my thoughts on the topic. Maybe some of this is related to messaging - would the proposed project be *an* LLVM libc or *the* LLVM libc. There is already at least one instance within the LLVM umbrella where a subproject designed and built to a particular set of constraints became *the* LLVM solution, and ended up disincentivizing investment from contributors whose priorities didn't match those constraints. Staking the blessed-by-LLVM slot for a piece of the toolchain is not free. To turn the question around, why should *this* libc (assuming it will be built whether or not LLVM accepts it) be *the* LLVM libc? --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/1608dc2e/attachment.html>
Saleem, Owen, others on the thread who are concerned about this: it seems that some of the concern is that the project goals are too narrow, and thus the eventual result may not serve the full community well over time. Would any of you be interested in what we should consider as the list of requirements for such a full solution? It would make it much easier to evaluate initial steps if we were to have a big picture of the problem to solve over time. -Chris> On Jun 27, 2019, at 1:19 PM, Owen Anderson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >>> On Jun 27, 2019, at 2:53 PM, Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> >>> So, what do you think about incorporating this new libc under the LLVM project? >> >> As stated, I really feel that this is far too specialised to certain use cases that are pertinent to Google. I think that this needs to be broadened to allow a general purpose libc much as libc++ is a general C++ implementation. I think that the project has a different set of requirements and seems like it would be extremely interesting to see how it would develop over time. This could really be an interesting choice for a certain type of project but as described feels like it is best explored outside of the umbrella of LLVM. >> > > I don't have a strong stake in this decision, but Saleem's commentary matches my thoughts on the topic. Maybe some of this is related to messaging - would the proposed project be *an* LLVM libc or *the* LLVM libc. There is already at least one instance within the LLVM umbrella where a subproject designed and built to a particular set of constraints became *the* LLVM solution, and ended up disincentivizing investment from contributors whose priorities didn't match those constraints. Staking the blessed-by-LLVM slot for a piece of the toolchain is not free. > > To turn the question around, why should *this* libc (assuming it will be built whether or not LLVM accepts it) be *the* LLVM libc? > > --Owen > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/e4f24141/attachment.html>
On Thu, Jun 27, 2019 at 2:05 PM Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Saleem, Owen, others on the thread who are concerned about this: it seems that some of the concern is that the project goals are too narrow, and thus the eventual result may not serve the full community well over time.May be my email listing our goals is being misinterpreted as being the bounding set of goals for the project. So, let me make it clear again: The goals I have listed are just our initial set of goals for the project. Members of the community are of course free to add their own goals to this set, implement them, and make it a "full solution." I have also mentioned in some of my earlier emails that we do not intend to design out any particular feature or platform. For example, I have said that we do not intend to work on dynamic linking/loading at least to begin with. This does not mean that the scope of the project is curtailed to static linking. The members of the community are free to add support for dynamic linking/loading. In fact, if dynamic linking/loading support is added in a modular/"as a library" fashion, it makes it a win-win situation as we will be able to take it out if we do not require it.> > -Chris > > On Jun 27, 2019, at 1:19 PM, Owen Anderson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Jun 27, 2019, at 2:53 PM, Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> So, what do you think about incorporating this new libc under the LLVM project? > > > As stated, I really feel that this is far too specialised to certain use cases that are pertinent to Google. I think that this needs to be broadened to allow a general purpose libc much as libc++ is a general C++ implementation. I think that the project has a different set of requirements and seems like it would be extremely interesting to see how it would develop over time. This could really be an interesting choice for a certain type of project but as described feels like it is best explored outside of the umbrella of LLVM. > > > I don't have a strong stake in this decision, but Saleem's commentary matches my thoughts on the topic. Maybe some of this is related to messaging - would the proposed project be *an* LLVM libc or *the* LLVM libc. There is already at least one instance within the LLVM umbrella where a subproject designed and built to a particular set of constraints became *the* LLVM solution, and ended up disincentivizing investment from contributors whose priorities didn't match those constraints. Staking the blessed-by-LLVM slot for a piece of the toolchain is not free. > > To turn the question around, why should *this* libc (assuming it will be built whether or not LLVM accepts it) be *the* LLVM libc? > > --Owen > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On Thu, Jun 27, 2019 at 2:05 PM Chris Lattner <clattner at nondot.org> wrote:> Saleem, Owen, others on the thread who are concerned about this: it seems > that some of the concern is that the project goals are too narrow, and thus > the eventual result may not serve the full community well over time. > > Would any of you be interested in what we should consider as the list of > requirements for such a full solution? It would make it much easier to > evaluate initial steps if we were to have a big picture of the problem to > solve over time. >Sure, I think that would be a good idea. Off the top of my head, something like this would be a good starting point: - a complete C11 standards compliant library (with complete support for dynamic linking - remember __declspec(dllimport)) - bundled dynamic loader which is capable of loading ELF/PE/MachO binaries - full TLS compatibility (including copy relocation) - compatible with OSes supported by LLVM (at least Windows, FreeBSD, Darwin, and Linux) - compatible with popular architectures supported by LLVM (at least x86, arm, arm64, and PPC) - portable code (e.g. no weak symbols) - ability to externalise (and even exclude!) locale data - optional POSIX layer - optional inclusion of C11 annexes - complete enough to replace the default system libc> -Chris > > On Jun 27, 2019, at 1:19 PM, Owen Anderson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Jun 27, 2019, at 2:53 PM, Saleem Abdulrasool via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > >> So, what do you think about incorporating this new libc under the LLVM >> project? >> > > As stated, I really feel that this is far too specialised to certain use > cases that are pertinent to Google. I think that this needs to be > broadened to allow a general purpose libc much as libc++ is a general C++ > implementation. I think that the project has a different set of > requirements and seems like it would be extremely interesting to see how it > would develop over time. This could really be an interesting choice for a > certain type of project but as described feels like it is best explored > outside of the umbrella of LLVM. > > > I don't have a strong stake in this decision, but Saleem's commentary > matches my thoughts on the topic. Maybe some of this is related to > messaging - would the proposed project be *an* LLVM libc or *the* LLVM > libc. There is already at least one instance within the LLVM umbrella > where a subproject designed and built to a particular set of constraints > became *the* LLVM solution, and ended up disincentivizing investment from > contributors whose priorities didn't match those constraints. Staking the > blessed-by-LLVM slot for a piece of the toolchain is not free. > > To turn the question around, why should *this* libc (assuming it will be > built whether or not LLVM accepts it) be *the* LLVM libc? > > --Owen > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/d7549470/attachment.html>