- User Since
- Aug 19 2016, 10:21 AM (48 w, 3 d)
Sat, Jul 22
Fri, Jul 21
Ping. I updated the description based on the email discussion with @majnemer.
Wed, Jul 19
Thanks for the explanations @rafael. Everything makes sense now.
Tue, Jul 18
(from @rafael's email) Correct, bfd complains. That is why you have to make foo weak, which is annoying.
I'm probably just misunderstanding the discussion here, but bfd complains about multiple definitions if you do .symver x, x@@VER: https://ghostbin.com/paste/c9b4t. Granted, I'm on an old version of binutils, so maybe that's changed?
Mon, Jul 17
Add comment for isDWARF
You probably wanna update the summary. We also generally recommend uploading patches with more context (pass -U9999 to your git commands), though it doesn't make much difference over here.
I discovered this because the .ARM.exidx end sentinel was getting incorrectly reordered away from the end of the section, leading to unwinding failing in certain binaries. CC @peter.smith, in case you've run into any similar issues.
Thu, Jul 13
Hmm, that's pretty ancient (and I would be surprised if that changed in newer versions). Lemme play with this some more.
Hmm, what version of gcc are you using? https://reviews.llvm.org/diffusion/L/browse/libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst;307951$86-90 suggests this may have changed recently.
Perfect. I'll throw up some patches.
Does P8004 fix operator+?
This doesn't look right to me. _LIBCPP_TEMPLATE_VIS expands to __attribute__((__type_visibility__("default"))) on compilers where __type_visibility__ is supported; i.e., its intent is to only export the typeinfo and vtable. gcc doesn't support this attribute, so we'll use __visibility__ instead and this change will appear to fix your issue, but it's not conceptually correct.
Mon, Jul 10
COFF supports weak externals: https://stackoverflow.com/a/11529277/382079. Would it suffice here?
Thu, Jul 6
(adding some Windows and cmake people)
Mon, Jul 3
Fri, Jun 30
Sorry about the breakage. I'll redo this limiting it to windows-itanium (and add a comment explaining why we want it).
Thu, Jun 29
Wed, Jun 28
Tue, Jun 27
Sorry, I've been meaning to respond for a while.
Mon, Jun 26
Thank you so much! This will be really helpful for me.
Jun 23 2017
This looks sensible to me. I don't know if there are any scenarios in which you'd be using the Microsoft CRT without having _MSC_VER defined, however. Added some people who may have a better idea of that (@compnerd, @majnemer and @rnk)
Jun 5 2017
Will just drop the .exe entirely, since that works
May 31 2017
May 29 2017
LGTM. Thanks for all the revisions!
May 17 2017
@sbc100 Normally you'd be able to accept the revision as an explicit LGTM. In this case, the revision had already been committed, so you don't have that option anymore.
May 14 2017
@compnerd see my previous comment:
May 10 2017
@EricWF and I discussed this on IRC a bit. I'm not a fan of overloading _LIBCPP_WIN32API for this purpose, since to me that macro is meant for guarding Windows API functions, not for CRT functions. Eric suggested adding a new macro _LIBCPP_MSVCRT_LIKE, which I'd be fine with.
Confirmed that there are no ABI changed on both Linux and macOS.
May 7 2017
Also ABI list checks for libc++abi sound awesome.
Fair enough. I'll probably get to that tomorrow.
Apr 28 2017
Empty sections causing a parse failure strikes me as slightly odd, but I'm guessing there's a good rationale for it. @compnerd?
Apr 27 2017
Apr 24 2017
Why not always replace the extension? Windows doesnt require the .exe suffix IIRC.
Thanks for the review!
Apr 21 2017
Apr 20 2017
Reduce nesting (address comments)
Apr 19 2017
This looks good to me, but I'm not familiar enough with this part of clang to be comfortable accepting.
Apr 18 2017
Apr 15 2017
Forgot to fix a test
Apr 13 2017