[scan-build] [Patch] Compiler call interceptor for Linux

[Laszlo Nagy]

hi Aleksei,

i did an extra check for you, and found that Bear has no issues to run
inside chroot. if you would call Bear outside of the chroot it will have
the extra path element to your chroot... (it is still produce a usable
output, although some post processing would be required. :))

i don't know how would you use osc. and how would you run the
analyzer/scan-build with osc... if i were you, i might create compilation
databases with rpmbuild macros (produced by cmake or Bear). and use that to
run scan-build or any other clang based tool. (maybe those could be also
rpmbuild macros as well.)

regards,
Laszlo


On Thu, May 15, 2014 at 12:26 PM, Aleksei Sidorin <a.sidorin at samsung.com>wrote:

>  Hello Laszlo,
>
> Thanks, that is interesting.
> I read this in Bear description:
> "The concept behind Bear is to exec the original build command and
> intercept the exec calls of the build tool. To achive that Bear uses the
> LD_PRELOAD or DYLD_INSERT_LIBRARIES mechanisms provided by the dynamic
> linker."
>
> I tried to escape this approach because it can face some problems with
> emulator-based build systems. For example, it can cause conflicts of build
> and interceptor architectures and there may be incorrect paths after
> chroot. If you are familiar with this tool, can you check it for correct
> work with chroot build environments (like osc:
> http://en.opensuse.org/openSUSE:Build_Service_Tutorial)? As I understand
> from description, it may have some problems with emulator-based build
> systems.
>
>
>
> 15.05.2014 12:11, Laszlo Nagy пишет:
>
> Interesting approach you have showed Aleksei. I had a similar problem, but
> approached it differently... I wrote a program which intercept the compiler
> calls and generate a compilation database. (you can generate it from cmake
> files) That tool is called bear <https://github.com/rizsotto/Bear>, and
> it works on linux/FreeBSD/OS X as well... And with the rewrite of
> scan-build wanted to extend the current functionality to use the
> compilation database (beside to work with the current environment based
> approach)... At this moment I still work on the ccc-analyzer implementation
> in python... Алексей Климов and Sylvestre Ledru in the frame of a GSoC also
> wanted to rewrite the scan-build part.
>
>
> On Tue, May 13, 2014 at 6:01 PM, Jordan Rose <jordan_rose at apple.com>wrote:
>
>> [+cfe-commits again, -cfe-dev]
>>
>> Interested yes, but unfortunately not all of the people involved in the
>> analyzer are using Linux systems. (I'm on OS X.) I've CC'd a few other
>> recent contributors to the analyzer, but I can't remember if they are
>> familiar with and have access to Linux systems either. (Laszlo in
>> particular is attempting to rewrite scan-build in Python, for more
>> uniformity with the rest of LLVM, so this is the sort of thing he'd want to
>> stay up-to-date about.)
>>
>> Sorry for not being so responsive here,
>> Jordan
>>
>>
>> On May 13, 2014, at 8:47 , Aleksei Sidorin <a.sidorin at samsung.com> wrote:
>>
>> > Hello again,
>> >
>> > I sent a message to cfe-commits mailing list, but nobody answered. This
>> task is listed in open projects. Is anybody interested in this interceptor?
>> >
>> > Link to review: http://reviews.llvm.org/D3608
>> >
>> > 29.04.2014 09:38, Aleksei Sidorin:
>> >> Hello,
>> >>
>> >> This patch enables interception of compiler calls without replacement
>> of environment variables. It uses strace (v.4.8) to compute root directory
>> of processes (in case of chroot), working directory, process name and its
>> environment variables and tries to guess some header directories. This
>> approach works well with Android and some build systems like OBS (local
>> build with osc client) and GBS (checked on Tizen). This behaviour can be
>> enabled with --use-interceptor option. If this option is not specified, old
>> behaviour is used (this patch was made to not break it).
>> >>
>> >> Interceptor uses process pool to analyze multiple files at a time.
>> Pool size can be specified with NUM_PROCESSES environment variable. Default
>> pool size is a number of processors.
>> >>
>> >> If we have a trace of build (that may be created with `strace -f -v -s
>> 1000000 -o $trace_file_name -e trace=vfork,fork,clone,execve,chdir,chroot
>> -e signal= $build_cmd`), it can be passed via TRACE_FILE environment
>> variable. This will not launch parallel build (analysis only). If option is
>> not specified, temporary pipe is used, analyzer and compiler are executed
>> in parallel.
>> >>
>> >> -additional-arg option was also added to pass additional parameters to
>> analyzer. Sometimes scan-build cannot determine all required parameters if
>> some custom toolchain is used.
>> >>
>> >> Interceptor was tested on Ubuntu 12.04 and 14.04 with strace 4.8.
>> Strace v.4.6 is known to have some issues with interception of gcc.
>> >>
>> >
>> >
>> > --
>> > Best regards,
>> > Aleksei Sidorin
>> > Software Engineer,
>> > IMSWL-IMCG, SRR, Samsung Electronics
>> >
>>
>>
>
>
> --
> Best regards,
> Aleksei Sidorin
> Software Engineer,
> IMSWL-IMCG, SRR, Samsung Electronics
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140515/e987282b/attachment.html>