<div dir="ltr"><div class="gmail_default" style>On Thu, Jan 17, 2013 at 4:39 AM, Evgeniy Stepanov <span dir="ltr"><<a href="mailto:eugeni.stepanov@gmail.com" target="_blank">eugeni.stepanov@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Jan 17, 2013 at 8:23 AM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br>

><br>
><br>
> ================<br>
> Comment at: lib/sanitizer_common/sanitizer_linux.cc:204<br>
> @@ -203,5 +203,3 @@<br>
><br>
> -void ReExec() {<br>
> -  static const int kMaxArgv = 100;<br>
> -  InternalScopedBuffer<char*> argv(kMaxArgv + 1);<br>
> -  static char *buff;<br>
> +static void ReadNullSepFileToArray(const char *path, char ***arr, int arr_size){<br>
> +  char *buff;<br>
> ----------------<br>
> Reid Kleckner wrote:<br>
>> Isn't /proc unavailable in many contexts, like chroots?  I believe function pointers in preinit_array receive argc, argv, and envp as arguments, which are forwarded straight from what the kernel put on the stack.  You may be able to use that instead.<br>

>> Isn't /proc unavailable in many contexts, like chroots?<br>
><br>
> I'm not convinced that we care enough about these contexts that we need to support them.  Besides, this code already has a dependency on /proc.<br></div></div></blockquote><div><br></div><div style>It might be nice to have at some point.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
>> I believe function pointers in preinit_array receive argc, argv, and envp as arguments, which are forwarded straight from what the kernel put on the stack. You may be able to use that instead.<br>
><br>
> The trouble is that (e.g.) __msan_init may be called from contexts from which we don't have access to these.  Perhaps one of the msan developers can enlighten us as to why .preinit_array isn't being used for msan.<br>

<br>
</div></div>Because we are OK with high-priority module constructor, and<br>
.preinit_array is problematic - you can not put it in a shared<br>
library, for example.<br>
<br>
We need __msan_init to happen before any instrumented code is<br>
executed, and not necessarily as the first thing in a process. Module<br>
constructor + checks in all interceptors work fine for that.<br>
<br>
AFAIK, constructors have access to envp through their arguments.<br></blockquote><div><br></div><div style>I did some experiments with this for DynamoRIO, and __attribute__((constructor)) may or may not get argv+envp depending on which gcc you are using.  Some time ago they switched from .ctors to .init_array, and .init_array gets argv+envp, but .ctors does not.</div>
<div style><br></div><div style>If you use _init, then that will get argv+envp too.</div></div></div></div>