How to give compiler arguments

How to give compiler arguments

[Martin Martin]

Hi,

If I put:

%{
#include "stdint.h"
%}

at the start of my probe script, stap says:


In file included from
/tmp/stapR3xMcm/stap_a41ca76a927c0e462ab230035f8677ed_1654_src.c:24:0:
/usr/lib/gcc/x86_64-linux-gnu/4.7/include/stdint.h:3:26: error: no
include path in which to search for stdint.h
make[1]: *** [/tmp/stapR3xMcm/stap_a41ca76a927c0e462ab230035f8677ed_1654_src.o]
Error 1

Is there a way to give some extra arguments to the compiler to resolve
this?  Or am I out of luck because it's a kernel module?

Thanks,
Martin

Re: How to give compiler arguments

[David Smith]

On 09/06/2013 01:42 PM, Martin Martin wrote:
> Hi,
> 
> If I put:
> 
> %{
> #include "stdint.h"
> %}
> 
> at the start of my probe script, stap says:
> 
> 
> In file included from
> /tmp/stapR3xMcm/stap_a41ca76a927c0e462ab230035f8677ed_1654_src.c:24:0:
> /usr/lib/gcc/x86_64-linux-gnu/4.7/include/stdint.h:3:26: error: no
> include path in which to search for stdint.h
> make[1]: *** [/tmp/stapR3xMcm/stap_a41ca76a927c0e462ab230035f8677ed_1654_src.o]
> Error 1
> 
> Is there a way to give some extra arguments to the compiler to resolve
> this?  Or am I out of luck because it's a kernel module?

Systemtap modules are real kernel modules, and thus have no access to
glibc (or its headers).

You can change the value of defines on the stap command line, like
'-DFOO=1'.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: How to give compiler arguments

[Josh Stone]

On 09/06/2013 11:42 AM, Martin Martin wrote:
> Hi,
> 
> If I put:
> 
> %{
> #include "stdint.h"
> %}
> 
> at the start of my probe script, stap says:
> 
> 
> In file included from
> /tmp/stapR3xMcm/stap_a41ca76a927c0e462ab230035f8677ed_1654_src.c:24:0:
> /usr/lib/gcc/x86_64-linux-gnu/4.7/include/stdint.h:3:26: error: no
> include path in which to search for stdint.h
> make[1]: *** [/tmp/stapR3xMcm/stap_a41ca76a927c0e462ab230035f8677ed_1654_src.o]
> Error 1
> 
> Is there a way to give some extra arguments to the compiler to resolve
> this?  Or am I out of luck because it's a kernel module?

That's the right line of thought -- as a kernel module, stap can only
include kernel headers.  We do have --runtime=dyninst which runs as a
shared object, but the usage model is a bit different there.

If "stdint.h" is really what you're after, then "linux/types.h" has a
lot of the same definitions, and is already included by default.  If
that's just an example and you're really after some purely userspace
definitions, you may be out of luck.  However, another option in stap
functions (not embedded-C) is to use @cast for user types, like:

  @cast(my_pointer, "Elf32_Ehdr", "<elf.h>")->e_machine.

Re: How to give compiler arguments

[Martin Martin]

Thanks a lot for your help.  I'm exploring the use of systemtap as the
core of a fault injection framework for a user-space program. Having
the probe script be able to modify return codes, local variables and
other values is quite attractive.  I can always put any complicated
functionality in my user application, and have systemtap trigger a
branch into it, e.g. by setting some local variable in my application.

Thanks,
Martin

On Fri, Sep 6, 2013 at 3:00 PM, Josh Stone <jistone@redhat.com> wrote:
> On 09/06/2013 11:42 AM, Martin Martin wrote:
>> Hi,
>>
>> If I put:
>>
>> %{
>> #include "stdint.h"
>> %}
>>
>> at the start of my probe script, stap says:
>>
>>
>> In file included from
>> /tmp/stapR3xMcm/stap_a41ca76a927c0e462ab230035f8677ed_1654_src.c:24:0:
>> /usr/lib/gcc/x86_64-linux-gnu/4.7/include/stdint.h:3:26: error: no
>> include path in which to search for stdint.h
>> make[1]: *** [/tmp/stapR3xMcm/stap_a41ca76a927c0e462ab230035f8677ed_1654_src.o]
>> Error 1
>>
>> Is there a way to give some extra arguments to the compiler to resolve
>> this?  Or am I out of luck because it's a kernel module?
>
> That's the right line of thought -- as a kernel module, stap can only
> include kernel headers.  We do have --runtime=dyninst which runs as a
> shared object, but the usage model is a bit different there.
>
> If "stdint.h" is really what you're after, then "linux/types.h" has a
> lot of the same definitions, and is already included by default.  If
> that's just an example and you're really after some purely userspace
> definitions, you may be out of luck.  However, another option in stap
> functions (not embedded-C) is to use @cast for user types, like:
>
>   @cast(my_pointer, "Elf32_Ehdr", "<elf.h>")->e_machine.
>