[LLVMdev] setrlimit vs ulimt

[Evgeniy Stepanov]

I'm always building against the standalone toolchain.
Without that, you really need to use the ndk build system, or manually
add a bunch of -I and -L flags, as headers and libraries for the
compiler and all the alternative sysroots and c++ stdlib
implementations are kept in separate places.


On Fri, May 30, 2014 at 11:07 PM, Greg Fitzgerald <garious at gmail.com> wrote:
>>>     %run sh -c "ulimit -s 8192 && %t"
>> This would not work
>
> I agree.  I think your idea of a target-compiled 'ulimit' is the best plan.
>
>
>> Btw, for some reason %run is defined in the top-level lit.cfg, and can
> not be redefined for individual configurations.
>
> Instead of overriding %run, set 'config.emulator'.
>
>
>> I guess that's because you are using the standalone
>> build? Perhaps we should all switch to that soon.
>
> The standalone build is really quite nice.  On my Linux box,
> Config+Build time for ARM build (ASan+UBSan): 35s.  x86_64+i386 of all
> sanitizers 45s.
>
>
> I just took a shot at building it for Android.  Choked in try_compile:
>
> android-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
> --sysroot=android-ndk-r9/platforms/android-18/arch-arm
> -Bandroid-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64
> -o simple.cc.o -c simple.cc
>
> simple.cc:2:18: fatal error: limits: No such file or directory
>  #include <limits>
>
> I see limits.h in the sysroot.  How do I help the NDK gcc find it?
> I'm trying to avoid making the standalone toolchain.  Is that dumb?
>
> Thanks,
> Greg
>
>
>
>
> On Fri, May 30, 2014 at 1:38 AM, Evgeniy Stepanov <eugenis at google.com> wrote:
>> On Fri, May 30, 2014 at 1:07 AM, Greg Fitzgerald <garious at gmail.com> wrote:
>>>  > 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"
>>
>> This would not work, because for now %run is empty, and %t is a
>> wrapper. Even if I move the logic to %run, it would need to map %t
>> (which is an absolute path on the host) to the device path somehow.
>>
>> Btw, for some reason %run is defined in the top-level lit.cfg, and can
>> not be redefined for individual configurations. I guess that's because
>> you are using the standalone build? Perhaps we should all switch to
>> that soon.
>>
>>>
>>> -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