setrlimit vs ulimt

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

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.

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

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?

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

> 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.

    %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

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.