Port osx_tls.c to D by jacob-carlborg · Pull Request #1582 · dlang/druntime

jacob-carlborg · 2016-06-01T21:18:02Z

No description provided.

Geod24 · 2016-06-02T02:36:35Z

Since it's OSX-specific, should it be in stdc ?

Geod24 · 2016-06-02T02:40:24Z

src/rt/sections_osx_x86_64.d

+        }
+    });
+
+    dyld_enumerate_tlv_storage(&handler);


This handler doesn't escape, does it ?
In which case the delegate literal at line 156 should be made a scope delegate to avoid needless memory allocation.
What is blocks semantic in that regard ? Is it mostly / only used for callback or can it be returned as a true delegate as well ?

This handler doesn't escape, does it ?

I really hope it doesn't because block returns by value and handler is on the stack, which will be gone after getTLSRange completes. I can look at the source code to confirm, but I would be very surprised.

In which case the delegate literal at line 156 should be made a scope delegate to avoid needless memory allocation.

Is that possible to do on the call site?

What is blocks semantic in that regard ? Is it mostly / only used for callback or can it be returned as a true delegate as well ?

What do you mean with "true delegate"? A closure that captures local variables which can be used after a function returns? Yes.

Is that possible to do on the call site?

Yes. Either you can use:

scope dg = (dyled_tlv_states state, dyld_tlv_info* info) { /*... */ } auto handler = block(dg);

You could change the definition of block to take a parameter of type scope R delegate(Params) dg which will mean delegate literals passed directly will never allocate. But see the next point.

What do you mean with "true delegate"? A closure that captures local variables which can be used after a function returns? Yes.

Quite a poor phrasing on my side, the question was actually "can the block escape the lexical scope in which it was declared", to which the answers seems to be yes (and so you can't use scope delegate for block's prototype).

scope dg = ...

Aha, I've never though of doing that for anything like but classes. I'll update that.

@Geod24 changed delegate to be scope.

Geod24 · 2016-06-02T03:02:26Z

Out of curiosity, what's the motivation behind the porting ?

jacob-carlborg · 2016-06-02T06:38:51Z

Out of curiosity, what's the motivation behind the porting ?

Dogfooding
I got some complains first time this was added and was not written in D
Why is the rest of druntime, DMD (half of it), or anything wirtten in D? 😃
Because I can 😃

jacob-carlborg · 2016-06-02T06:44:58Z

Since it's OSX-specific, should it be in stdc ?

I don't know, suggestions are welcome. I had to put it somewhere. I quick search on google suggest that it works on Linux as well with the correct runtime libraries installed. I can do a test and confirm.

jacob-carlborg · 2016-06-02T07:10:57Z

I just did a test in a Debian container, following these instructions [1], and it works perfectly fine.

[1] http://stackoverflow.com/a/11097610

jacob-carlborg · 2016-06-02T07:12:36Z

I'll add some code to make it possible to call blocks from the D side as well.

jacob-carlborg · 2016-06-02T07:15:07Z

Suggestions for the naming convention would be appreciated as well. I think the official name is "Blocks" but I called it "Clang Blocks" for now. To avoid confusion with a regular block. Perhaps "Block" with a capital letter is enough to avoid any confusion.

jacob-carlborg · 2016-06-02T07:55:11Z

@MartinNowak osx_tls.c is now ported to D.

jacob-carlborg · 2016-06-05T19:03:51Z

I'll add some code to make it possible to call blocks from the D side as well.

I'll skip this because the Block struct need to look different depending on if any local variables are captured on the C side. This seems a bit too complicated.

jacob-carlborg · 2016-06-05T20:59:58Z

Ok, all tests are passing.

schveiguy · 2016-06-06T15:40:06Z

src/rt/osx_tls.c

-#ifndef __BLOCKS__
- #error "Need a C compiler with Apple Blocks support – not building on OS X with Clang?"
-#endif
-#endif


Is there an equivalent test needed in the D version? That is, what happens if you are building on something other than OSX, or linking with non-clang libc?

I totally admit, I'm not sure what should be done, I'm just pointing out a difference between the C code and the D code.

The content of this file is moved into sections_osx_x86_64.d, which is already properly guarded for OS X 64bit.

The code which makes calling Blocks possible, clang_block.d, is cross-platform. Using that code only make sense if you have a C function taking Block you want to call. That C code needs to be compiled with Clang, and linking that on non-Apple platforms requires the Blocks runtime, which is noted in the documentation. We can't do anything, as far as I know, on the D side to enforce this.

If you try to compile the C code with something else than Clang you'll get a syntax error. Linking without the Blocks runtime will cause undefined symbol errors.

So far the tests for clang_block.d is only enabled on OS X because it has everything required out of the box. If we install Clang and the Blocks runtime on the other machines used by the autotester I can enable it for those other platforms as well.

Geod24 · 2016-06-06T21:21:30Z

I don't know, suggestions are welcome. I had to put it somewhere. I quick search on google suggest that it works on Linux as well with the correct runtime libraries installed. I can do a test and confirm.

I would definitely not put it in stdc, as its for C standard library.

Either we can have a core.clang package, but that seems like a dangerous precedent, or as part of core.sys.osx[.clang]. Last but not least, it could be in an internal module, like rt.
I am leaning towards the later option.

Geod24 · 2016-06-06T21:22:29Z

src/core/stdc/clang_block.d

+ * License:   $(LINK2 http://www.boost.org/LICENSE_1_0.txt, Boost License 1.0)
+ * Authors:   Jacob Carlborg
+ * Source:    $(DRUNTIMESRC core/_clang_block.d)
+ */


Kudos for documentation !

jacob-carlborg · 2016-06-07T15:28:45Z

Either we can have a core.clang package, but that seems like a dangerous precedent, or as part of core.sys.osx[.clang]. Last but not least, it could be in an internal module, like rt.
I am leaning towards the later option.

It works on other platforms than OS X (that's why I put it in core.stdc) but I guessing it's not going to be used on any non-Apple platform. I did not want to put it in the rt package because it's useful outside of the runtime.

Geod24 · 2016-06-07T18:50:14Z

It works on other platforms than OS X (that's why I put it in core.stdc) but I guessing it's not going to be used on any non-Apple platform. I did not want to put it in the rt package because it's useful outside of the runtime.

I think we should separate what is used for implementing the runtime and what druntime expose.
There is a great deal of overlap thanks to libc, but I don't think we should expose this one.

jacob-carlborg · 2016-06-08T06:30:33Z

I think we should separate what is used for implementing the runtime and what druntime expose.
There is a great deal of overlap thanks to libc

There's a specific reason why I chose to expose the Blocks related code. That's because it's very useful to be able to interface with functions taking Blocks on OS X.

but I don't think we should expose this one.

I don't see a reason why not.

Clang Blocks, or just Blocks [1], is an extension to the C family of languages which adds support for anonymous functions, much like delegates in D. Being able to interface with Blocks is important when interfacing with Apple specific API's since some of the API's are only available in a form requiring using Blocks. Interfacing with Blocks is done by directly using the underlying ABI. A Block basically consist of a struct containing a function pointer to the body of the Block, any captured values and some metadata. The ABI that is used is the Apple ABI [2]. It's possible to use Blocks on non-Apple platforms as well. This requires to compile the C code using Clang and install and link with the Blocks runtime [3]. [1] Language specification for Blocks: http://clang.llvm.org/docs/BlockLanguageSpec.html [2] http://clang.llvm.org/docs/Block-ABI-Apple.html [3] http://compiler-rt.llvm.org

Geod24 · 2016-06-11T14:27:48Z

There's a specific reason why I chose to expose the Blocks related code. That's because it's very useful to be able to interface with functions taking Blocks on OS X.
[...]
I don't see a reason why not.

Okay, let's wait for some other opinion on this topic then.

MartinNowak · 2016-06-19T20:26:29Z

Blocks aren't standard C, so they don't belong into core.stdc, use core.sys.osx.something.
If the ported D version doesn't rely on hacks (looks like http://clang.llvm.org/docs/Block-ABI-Apple.html), then replacing the C code is fine with me.

dnadlinger · 2016-06-19T20:33:48Z

sys.osx isn't really correct either, though, since they are not OS X-specific (even though obviously developed by Apple). It's a Clang thing.

jacob-carlborg · 2016-06-20T07:27:47Z

If the ported D version doesn't rely on hacks (looks like http://clang.llvm.org/docs/Block-ABI-Apple.html), then replacing the C code is fine with me.

Not sure what you mean with "hacks". But yes, it uses/follows http://clang.llvm.org/docs/Block-ABI-Apple.html

jacob-carlborg · 2016-06-20T07:29:17Z

sys.osx isn't really correct either, though, since they are not OS X-specific (even though obviously developed by Apple). It's a Clang thing.

Exactly. If we install Clang and the Blocks Runtime on the autotester machines I could enable the tests on more platforms.

jacob-carlborg force-pushed the osx_tls_d branch from d67272b to 6c9a2c9 Compare June 1, 2016 21:20

Geod24 reviewed Jun 2, 2016
View reviewed changes

jacob-carlborg force-pushed the osx_tls_d branch 3 times, most recently from d7db859 to 9551eba Compare June 5, 2016 19:02

jacob-carlborg force-pushed the osx_tls_d branch from 9551eba to cea56eb Compare June 5, 2016 20:47

schveiguy reviewed Jun 6, 2016
View reviewed changes

Geod24 reviewed Jun 6, 2016
View reviewed changes

jacob-carlborg added 2 commits June 10, 2016 10:24

Port osx_tls.c to D

550edd0

jacob-carlborg force-pushed the osx_tls_d branch from cea56eb to 550edd0 Compare June 10, 2016 08:24

jacob-carlborg closed this Aug 18, 2016

jacob-carlborg deleted the osx_tls_d branch August 18, 2016 14:19

jacob-carlborg mentioned this pull request Aug 26, 2017

Clang blocks are incorrectly translated to function pointers jacob-carlborg/dstep#159

Open

Uh oh!

Conversation

jacob-carlborg commented Jun 1, 2016

Uh oh!

Geod24 commented Jun 2, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Geod24 commented Jun 2, 2016

Uh oh!

jacob-carlborg commented Jun 2, 2016

Uh oh!

jacob-carlborg commented Jun 2, 2016

Uh oh!

jacob-carlborg commented Jun 2, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacob-carlborg commented Jun 2, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacob-carlborg commented Jun 2, 2016

Uh oh!

jacob-carlborg commented Jun 2, 2016

Uh oh!

jacob-carlborg commented Jun 5, 2016

Uh oh!

jacob-carlborg commented Jun 5, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Geod24 commented Jun 6, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacob-carlborg commented Jun 7, 2016

Uh oh!

Geod24 commented Jun 7, 2016

Uh oh!

jacob-carlborg commented Jun 8, 2016

Uh oh!

Geod24 commented Jun 11, 2016

Uh oh!

MartinNowak commented Jun 19, 2016

Uh oh!

dnadlinger commented Jun 19, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacob-carlborg commented Jun 20, 2016

Uh oh!

jacob-carlborg commented Jun 20, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

jacob-carlborg commented Jun 2, 2016 •

edited

Loading

jacob-carlborg commented Jun 2, 2016 •

edited

Loading

dnadlinger commented Jun 19, 2016 •

edited

Loading