> execv(argv[0]) is a canonical way to restart the > process, it's sad that the emulator interferes with that.We have the option to emulate the instruction set or emulate the OS. The former is lighter weight and easy to configure. The downside is that system calls route to the host system. That can be useful if, for example, the executable invokes llvm-symbolizer. While execv(argv[0]) may be the right way to restart, this process doesn't need to be restarted. It needs to be configured before the first invocation.> Propagating ulimit setting in %run wrapper sounds wrong.In my opinion, propagating ulimit settings in the wrapper is consistent with whitelisting environment variables. -Greg On Thu, May 29, 2014 at 2:34 AM, Evgeniy Stepanov <eugenis at google.com> wrote:> execv(argv[0]) is a canonical way to restart the process, it's sad > that the emulator interferes with that. > > ulimit does not work for me because it needs to run on the device, in > the same shell as the test binary. > Propagating ulimit setting in %run wrapper sounds wrong. > > > On Wed, May 28, 2014 at 11:43 PM, Greg Fitzgerald <garious at gmail.com> wrote: >> Hi Evgeniy, >> >> This fix causes me trouble in the emulator because of the execv(argv[0]): >> >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140217/205359.html >> >> Instead using setrlimit from within the C++ code, can you set the >> stack limit using ulimit on the RUN lines? Also, should this test be >> moved to the Posix or Linux directory? >> >> Thanks, >> Greg
On Thu, May 29, 2014 at 10:44 PM, Greg Fitzgerald <garious at gmail.com> wrote:>> execv(argv[0]) is a canonical way to restart the >> process, it's sad that the emulator interferes with that. > > We have the option to emulate the instruction set or emulate the OS. > The former is lighter weight and easy to configure. The downside is > that system calls route to the host system. That can be useful if, > for example, the executable invokes llvm-symbolizer. > > While execv(argv[0]) may be the right way to restart, this process > doesn't need to be restarted. It needs to be configured before the > first invocation.I must be missing something here. Why does fork-exec for llvm-symbolizer work, but simple exec(self) does not? Is it because argv[0] is not what it normally is? Can it be worked around?> > >> Propagating ulimit setting in %run wrapper sounds wrong. > > In my opinion, propagating ulimit settings in the wrapper is > consistent with whitelisting environment variables.Target platform may be quite different from host and simply replicating the entire "ulimit -a" would be wrong. Ideally, we need to propagate only those limits that were set explicitly in the test. Could we write a ulimit-like utility that would do setrlimit and then exec the specified binary, like %run %ulimit -s 8192 %t?> > -Greg > > On Thu, May 29, 2014 at 2:34 AM, Evgeniy Stepanov <eugenis at google.com> wrote: >> execv(argv[0]) is a canonical way to restart the process, it's sad >> that the emulator interferes with that. >> >> ulimit does not work for me because it needs to run on the device, in >> the same shell as the test binary. >> Propagating ulimit setting in %run wrapper sounds wrong. >> >> >> On Wed, May 28, 2014 at 11:43 PM, Greg Fitzgerald <garious at gmail.com> wrote: >>> Hi Evgeniy, >>> >>> This fix causes me trouble in the emulator because of the execv(argv[0]): >>> >>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140217/205359.html >>> >>> Instead using setrlimit from within the C++ code, can you set the >>> stack limit using ulimit on the RUN lines? Also, should this test be >>> moved to the Posix or Linux directory? >>> >>> Thanks, >>> Greg
> Why does fork-exec for llvm-symbolizer work, but simple exec(self) does not?Because the llvm-symbolizer the runtime finds is built for the host architecture. This is weird, yes, but once we integrate the symbolizer, it goes away.> Could we write a ulimit-like utility that would do setrlimit and then > exec the specified binary > %run %ulimit -s 8192 %t?I like that idea. How do you feel about this short-term solution: %run sh -c "ulimit -s 8192 && %t" -Greg On Thu, May 29, 2014 at 12:05 PM, Evgeniy Stepanov <eugenis at google.com> wrote:> On Thu, May 29, 2014 at 10:44 PM, Greg Fitzgerald <garious at gmail.com> wrote: >>> execv(argv[0]) is a canonical way to restart the >>> process, it's sad that the emulator interferes with that. >> >> We have the option to emulate the instruction set or emulate the OS. >> The former is lighter weight and easy to configure. The downside is >> that system calls route to the host system. That can be useful if, >> for example, the executable invokes llvm-symbolizer. >> >> While execv(argv[0]) may be the right way to restart, this process >> doesn't need to be restarted. It needs to be configured before the >> first invocation. > > I must be missing something here. Why does fork-exec for > llvm-symbolizer work, but simple exec(self) does not? > Is it because argv[0] is not what it normally is? Can it be worked around? > >> >> >>> Propagating ulimit setting in %run wrapper sounds wrong. >> >> In my opinion, propagating ulimit settings in the wrapper is >> consistent with whitelisting environment variables. > > Target platform may be quite different from host and simply > replicating the entire "ulimit -a" would be wrong. Ideally, we need to > propagate only those limits that were set explicitly in the test. > Could we write a ulimit-like utility that would do setrlimit and then > exec the specified binary, like %run %ulimit -s 8192 %t? > > >> >> -Greg >> >> On Thu, May 29, 2014 at 2:34 AM, Evgeniy Stepanov <eugenis at google.com> wrote: >>> execv(argv[0]) is a canonical way to restart the process, it's sad >>> that the emulator interferes with that. >>> >>> ulimit does not work for me because it needs to run on the device, in >>> the same shell as the test binary. >>> Propagating ulimit setting in %run wrapper sounds wrong. >>> >>> >>> On Wed, May 28, 2014 at 11:43 PM, Greg Fitzgerald <garious at gmail.com> wrote: >>>> Hi Evgeniy, >>>> >>>> This fix causes me trouble in the emulator because of the execv(argv[0]): >>>> >>>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140217/205359.html >>>> >>>> Instead using setrlimit from within the C++ code, can you set the >>>> stack limit using ulimit on the RUN lines? Also, should this test be >>>> moved to the Posix or Linux directory? >>>> >>>> Thanks, >>>> Greg