C Instrumentation Framework

There are only 7 drivers affected. Not that important, I guess.

As well as #1158 issue.

Eugene Novikov wrote:

As I understand just mem_ref tree node isn't supported at the moment.

And this is the case! 9 drivers of linux-2.6.37 aren't processed because of the given reason.

For example:

.../artificial_env_1/csd_deg_dscv/11/dscv_tempdir/dscv/ri/43_1a/drivers/base/core.c.p: In function 'dev_set_name': 
.../artificial_env_1/csd_deg_dscv/11/dscv_tempdir/dscv/ri/43_1a/drivers/base/core.c.p:825:1: error: LDV:
/home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-src/gcc/c-family/ldv-convert.c: 5214: tree node 'reference_type' isn't supported

Moreover, because of the given issue, aspectator doesn't like constructions intended for new gcc. For instance, from arch/x86/include/asm/string_64.h:

#if (__GNUC__ == 4 && __GNUC_MINOR__ >= 3) || __GNUC__ > 4
extern void *memcpy(void *to, const void *from, size_t len);
#else
extern void *__memcpy(void *to, const void *from, size_t len);
#define memcpy(dst, src, len)                                   \
({                                                              \
        size_t __len = (len);                                   \
        void *__ret;                                            \
        if (__builtin_constant_p(len) && __len >= 64)           \
                __ret = __memcpy((dst), (src), __len);          \
        else                                                    \
                __ret = __builtin_memcpy((dst), (src), __len);  \
        __ret;                                                  \
})
#endif

work/current--X--online-drivers--from_oldserv--wl12xx.tar.bz2.tar.bz2--X--defaultlinux-2.6.31.6--X--29_1/linux-2.6.31.6/csd_deg_dscv/2/dscv_tempdir/dscv/ri/29_1/main.c.p: In function 'wl12xx_build_null_data':
work/current--X--online-drivers--from_oldserv--wl12xx.tar.bz2.tar.bz2--X--defaultlinux-2.6.31.6--X--29_1/linux-2.6.31.6/csd_deg_dscv/2/dscv_tempdir/dscv/ri/29_1/main.c.p:485:1: error: LDV: aspectator-core-src/gcc/ldv-pointcut-matcher.c: 310: tree node 'mem_ref' isn't supported

Is it difficult to fix in c-backend/aspectator?

Alexey Khoroshilov wrote:

Is it difficult to fix in c-backend/aspectator?

We should do it this week because of we have corresponding user story :) But nevertheless we have to keep options that hide actual gcc version used because of #1323 issue.

At the moment because of #1323 bug "resolution" the issue has gone away, but we should fix it as well as the original one (since they are simply the same indeed).

After all, the problem with mem_ref was fixed by adding option -fno-builtin to the aspectator core (i.e. modified gcc) ones. This prevents changes of functions like strcpy, memcpy and a lot of others to gcc builtin functions (__builtin_strcpy, __builtin_memcpy and so on). Moreover, it leaded to total absence of MEM_REF.

The problem connected with reference_type is the architecture problem indeed. After thorough investigation I have found that it comes from gcc/config/i386/i386.c:

static tree
ix86_build_builtin_va_list_abi (enum calling_abi abi)
{
  tree f_gpr, f_fpr, f_ovf, f_sav, record, type_decl;

  /* For i386 we use plain pointer to argument area.  */
  if (!TARGET_64BIT || abi == MS_ABI)
    return build_pointer_type (char_type_node);

  ...

  /* The correct type is an array type of one element.  */
  return build_array_type (record, build_index_type (size_zero_node));
}

void
c_common_nodes_and_builtins (void)
{
  ...

  if (TREE_CODE (va_list_type_node) == ARRAY_TYPE)
    {
      va_list_arg_type_node = va_list_ref_type_node =
    build_pointer_type (TREE_TYPE (va_list_type_node));
    }
  else
    {
      va_list_arg_type_node = va_list_type_node;
      va_list_ref_type_node = build_reference_type (va_list_type_node);
    }
  ...
}

  __builtin_va_start ( ( /* LDV: /home/tester/ldv/ldv-tools/rule-instrumentor/aspectator/gcc-4.6/__install/aspectator-core-src/gcc/c-family/ldv-pretty-print.c: 3600: specifier qualifier list of type name wasn't printed */ ) ( __builtin_va_list **) & vargs , fmt );

Eugene Novikov wrote:

After all, the problem with mem_ref was fixed by adding option -fno-builtin to the aspectator core (i.e. modified gcc) ones. This prevents changes of functions like strcpy, memcpy and a lot of others to gcc builtin functions (__builtin_strcpy, __builtin_memcpy and so on). Moreover, it leaded to total absence of MEM_REF.

The fix is available in master commit:b542cb99e

I do not see any memref errors on my machine. Perhaps, it's the x86 issue again.

Pavel Shved wrote:

I do not see any memref errors on my machine. Perhaps, it's the x86 issue again.

Absolutely correctly! Again the issue presents just on x86 architecture and it is connected with hard coded __builtin_memcpy:

# 181 "/home/tester/ldv/workdir/envs/1/shadows/arch/x86/include/asm/string_32.h" 
#if (__GNUC__ >= 4)
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
#else
#define memcpy(t, f, n)> \
 (__builtin_constant_p((n)) \
 ? __constant_memcpy((t), (f), (n)) \
 : __memcpy((t), (f), (n)))
#endif

This is a problem also for non x86 architecture (e.g. for x86_64) since nevertheless somebody can use __builtin_memcpy directly for instance. I can reproduce the problem by means of the following short example:

struct AAA
{
 char name[100];
};
int f(struct AAA *DDD)
{
 unsigned char tmp[10];
 __builtin_memcpy(DDD->name, tmp, 10);
}

So the generated code will just contain "memcpy" calls et al, and won't unroll it into built-in functions?

Pavel Shved wrote:

So the generated code will just contain "memcpy" calls et al, and won't unroll it into built-in functions?

It will contain just those things that were originally. For instance, on x86 there is a macro that convert memcpy into __builtin_memcpy (see comment 20), so after aspectator we should also obtain a call to __builtin_memcpy (instead of current problems with MEM_REF) if somebody doesn't prohibit the macro expansion above (e.g. by means of aspect file).