On Wed, Apr 22, 2015 at 5:12 PM, Renato Golin <renato.golin at linaro.org> wrote:> On 22 April 2015 at 03:40, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> So after a bit of a hiatus (sorry, other stuff has been eating up my free >> time), Id like to pick this up again. I think that its a matter of just >> copying the unwind sources into the right place. Im hoping to do this >> sometime this Friday (or perhaps Saturday). Any objections? I can probably >> try to take a stab with the CMake side of things once the repo is copied >> over. > > Hi Saleem, > > Thanks for looking at it again, this may simplify the FreeBSD usage of > compiler-rt a lot (they still use libgcc_s/eh with it). > > I imagine that copying the files will be the simple part. More complex > will be to make sure that they're built in the same way (so updating > both CMale files to add/remove logic), and making sure to move all > tests and get them to run when you do a make check on compiler-rt. > > However, the worse part will probably making sure that both > compiler-rt and libc++abi have unwind for a period of time, to allow > everyone to migrate whatever they do, and only kill it after a period > of time. I'd vote for not having a release with the unwinding code on > both places, but having them in trunk for a month or so, with weekly > warnings will probably help a lot people that rely on it.No way - that would be super confusing at best. "they" will have to migrate eventually and the sooner that clean cut happens, the better. Having a release with both would be a nightmare.
Really dumb question. Why do we need libcxxabi at all? Can we move it all into compiler-rt and have less repos? I don't see what's all that different between the sanitizer run times and the bits of c++ rt in libcxxabi. Sent from phone On Apr 22, 2015 3:17 AM, "C Bergström" <cbergstrom at pathscale.com> wrote:> On Wed, Apr 22, 2015 at 5:12 PM, Renato Golin <renato.golin at linaro.org> > wrote: > > On 22 April 2015 at 03:40, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > >> So after a bit of a hiatus (sorry, other stuff has been eating up my > free > >> time), Id like to pick this up again. I think that its a matter of just > >> copying the unwind sources into the right place. Im hoping to do this > >> sometime this Friday (or perhaps Saturday). Any objections? I can > probably > >> try to take a stab with the CMake side of things once the repo is copied > >> over. > > > > Hi Saleem, > > > > Thanks for looking at it again, this may simplify the FreeBSD usage of > > compiler-rt a lot (they still use libgcc_s/eh with it). > > > > I imagine that copying the files will be the simple part. More complex > > will be to make sure that they're built in the same way (so updating > > both CMale files to add/remove logic), and making sure to move all > > tests and get them to run when you do a make check on compiler-rt. > > > > However, the worse part will probably making sure that both > > compiler-rt and libc++abi have unwind for a period of time, to allow > > everyone to migrate whatever they do, and only kill it after a period > > of time. I'd vote for not having a release with the unwinding code on > > both places, but having them in trunk for a month or so, with weekly > > warnings will probably help a lot people that rely on it. > > No way - that would be super confusing at best. "they" will have to > migrate eventually and the sooner that clean cut happens, the better. > Having a release with both would be a nightmare. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150422/e7fa2f01/attachment.html>
On 4/22/15 10:04 AM, Reid Kleckner wrote:> Really dumb question. Why do we need libcxxabi at all? > Can we move it all into compiler-rt and have less repos?Oh no, not this monster thread... again. :( By the same rhetoric, why have separate repositories for Clang and LLVM? Separation of libraries by repository is *good* for keeping out layering violations. It's hard enough to keep ourselves "honest" w.r.t. that as-is (hence moving the unwinder out of libcxxabi).> I don't see what's all that different between the sanitizer run times > and the bits of c++ rt in libcxxabi.The fundamental difference is that the sanitizer runtimes don't fully implement the Itanium ABI, whereas libcxxabi does... they're only shims for a few "interesting" functions in that library. Also, can't the sanitizers be used with libcxxrt too? As a sidenote, IMHO the sanitizers should be in their own repository too, not bundled with compiler_rt... but that's a whole other monster of a discussion. Cheers, Jon> > Sent from phone > > On Apr 22, 2015 3:17 AM, "C Bergström" <cbergstrom at pathscale.com > <mailto:cbergstrom at pathscale.com>> wrote: > > On Wed, Apr 22, 2015 at 5:12 PM, Renato Golin > <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> wrote: > > On 22 April 2015 at 03:40, Saleem Abdulrasool > <compnerd at compnerd.org <mailto:compnerd at compnerd.org>> wrote: > >> So after a bit of a hiatus (sorry, other stuff has been eating > up my free > >> time), Id like to pick this up again. I think that its a matter > of just > >> copying the unwind sources into the right place. Im hoping to > do this > >> sometime this Friday (or perhaps Saturday). Any objections? I > can probably > >> try to take a stab with the CMake side of things once the repo > is copied > >> over. > > > > Hi Saleem, > > > > Thanks for looking at it again, this may simplify the FreeBSD > usage of > > compiler-rt a lot (they still use libgcc_s/eh with it). > > > > I imagine that copying the files will be the simple part. More > complex > > will be to make sure that they're built in the same way (so updating > > both CMale files to add/remove logic), and making sure to move all > > tests and get them to run when you do a make check on compiler-rt. > > > > However, the worse part will probably making sure that both > > compiler-rt and libc++abi have unwind for a period of time, to allow > > everyone to migrate whatever they do, and only kill it after a period > > of time. I'd vote for not having a release with the unwinding code on > > both places, but having them in trunk for a month or so, with weekly > > warnings will probably help a lot people that rely on it. > > No way - that would be super confusing at best. "they" will have to > migrate eventually and the sooner that clean cut happens, the better. > Having a release with both would be a nightmare. > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded
On Wed, Apr 22, 2015 at 3:17 AM, C Bergström <cbergstrom at pathscale.com> wrote:> On Wed, Apr 22, 2015 at 5:12 PM, Renato Golin <renato.golin at linaro.org> > wrote: > > On 22 April 2015 at 03:40, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > >> So after a bit of a hiatus (sorry, other stuff has been eating up my > free > >> time), Id like to pick this up again. I think that its a matter of just > >> copying the unwind sources into the right place. Im hoping to do this > >> sometime this Friday (or perhaps Saturday). Any objections? I can > probably > >> try to take a stab with the CMake side of things once the repo is copied > >> over. > > > > Hi Saleem, > > > > Thanks for looking at it again, this may simplify the FreeBSD usage of > > compiler-rt a lot (they still use libgcc_s/eh with it). > > > > I imagine that copying the files will be the simple part. More complex > > will be to make sure that they're built in the same way (so updating > > both CMale files to add/remove logic), and making sure to move all > > tests and get them to run when you do a make check on compiler-rt. > > > > However, the worse part will probably making sure that both > > compiler-rt and libc++abi have unwind for a period of time, to allow > > everyone to migrate whatever they do, and only kill it after a period > > of time. I'd vote for not having a release with the unwinding code on > > both places, but having them in trunk for a month or so, with weekly > > warnings will probably help a lot people that rely on it. > > No way - that would be super confusing at best. "they" will have to > migrate eventually and the sooner that clean cut happens, the better. > Having a release with both would be a nightmare. >I agree. Once the files are copied, we should immediately kill the old copy. Leaving it in will only confuse everyone. Where do I commit to? Oh, I just committed it here and not there. Trying to reconcile the divergences afterwards will not end well IMO. -- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150422/9eae79af/attachment.html>
Ok. If everyone is happy about it, looks good. Cheers, Renato On 23 Apr 2015 2:31 am, "Saleem Abdulrasool" <compnerd at compnerd.org> wrote:> On Wed, Apr 22, 2015 at 3:17 AM, C Bergström <cbergstrom at pathscale.com> > wrote: > >> On Wed, Apr 22, 2015 at 5:12 PM, Renato Golin <renato.golin at linaro.org> >> wrote: >> > On 22 April 2015 at 03:40, Saleem Abdulrasool <compnerd at compnerd.org> >> wrote: >> >> So after a bit of a hiatus (sorry, other stuff has been eating up my >> free >> >> time), Id like to pick this up again. I think that its a matter of >> just >> >> copying the unwind sources into the right place. Im hoping to do this >> >> sometime this Friday (or perhaps Saturday). Any objections? I can >> probably >> >> try to take a stab with the CMake side of things once the repo is >> copied >> >> over. >> > >> > Hi Saleem, >> > >> > Thanks for looking at it again, this may simplify the FreeBSD usage of >> > compiler-rt a lot (they still use libgcc_s/eh with it). >> > >> > I imagine that copying the files will be the simple part. More complex >> > will be to make sure that they're built in the same way (so updating >> > both CMale files to add/remove logic), and making sure to move all >> > tests and get them to run when you do a make check on compiler-rt. >> > >> > However, the worse part will probably making sure that both >> > compiler-rt and libc++abi have unwind for a period of time, to allow >> > everyone to migrate whatever they do, and only kill it after a period >> > of time. I'd vote for not having a release with the unwinding code on >> > both places, but having them in trunk for a month or so, with weekly >> > warnings will probably help a lot people that rely on it. >> >> No way - that would be super confusing at best. "they" will have to >> migrate eventually and the sooner that clean cut happens, the better. >> Having a release with both would be a nightmare. >> > > I agree. Once the files are copied, we should immediately kill the old > copy. Leaving it in will only confuse everyone. Where do I commit to? > Oh, I just committed it here and not there. Trying to reconcile the > divergences afterwards will not end well IMO. > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150423/07c540a8/attachment.html>