This patch splits up hwasan thread creation between __sanitizer_before_thread_create_hook, __sanitizer_thread_create_hook, and __sanitizer_thread_start_hook. The linux implementation creates the hwasan thread object inside the new thread. On Fuchsia, we know the stack bounds before thread creation, so we can initialize part of the thread object in __sanitizer_before_thread_create_hook, then initialize the stack ring buffer in __sanitizer_thread_start_hook once we enter the thread.
Usually we like to split changes up into separate small changes for the pure refactoring, and then changes that purely add new Fuchsia-specific code.
I'll do an initial review round of the Fuchsia code here since you've sent it. But then I think this review should be tightened to just the pure refactoring, and we should have a separate review thread for the Fuchsia parts.
Specifically call out here that the compiler generates direct TLS references to this and that's why it has a public C ABI name.
For Fuchsia the hwasan will always be in a DSO that is a dependency of libc.so and so always loaded at startup. Hence we can use [[gnu::tls_model("initial-exec")]] here.
department of redundancy department
Nit: I'd call it something more like InitState.
What depends on this alignment? I'm not aware of anything that does in the compiler ABI we're using on Fuchsia.
Actually we could do all of the allocation and setup except for storing the uptr in __hwasan_tls.
Most of what's happening in this function is common with the Linux code.
This is stuff that could be done either in the before-create hook or in the on-start hook. But it's probably not especially worthwhile to move it to before-create as long as we have on-start doing any allocation at all. So to avoid a whole lot more refactoring to move the ringbuffer setup and such, might as well just leave this in on-start too.
This is probably the only part that actually needs to be different between Linux and Fuchsia.
|85 ↗||(On Diff #351313)|
I think these need to be left uniformly uninitialized to guarantee they can be "linker-initialized".
Rebased against recent refactoring commits and addressed some comments.
I think I can omit some functions like GetCurrentThread or GetRingBufferSize which are small enough to merit their own changes .
Updated such that this just calls InitStackRingBuffer which handles the stack ring buffer initialization.
With the refactoring from D104248, this bit will be done in the before-create hook without any changes to this code.
This is done in D104248.