Bug #1165
closedGCC-aspectator fails with fatal error: incorrect reference code
Added by Pavel Shved about 13 years ago. Updated over 11 years ago.
0%
Description
Steps to reproduce:
LDV_DEBUG=30 ldv-manager rule_models=32_1a "envs=linux-2.6.31.6.tar.bz2" drivers=drivers/ieee1394/eth1394.ko kernel_driver=1 name=ri13
Excerpt from the error message:
/home/pavel/work/ldv/test/work/current--X--drivers/ieee1394/eth1394.ko--X--ri13linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/11/dscv_tempdir/dscv/ri/32_1a/drivers/ieee1394/eth1394.c.p:1721:1: fatal error: incorrect reference code compilation terminated. Aspectator fails on the 3d stage
Excerpt from the code:
1716 static void ether1394_get_drvinfo(struct net_device *dev,
1717 struct ethtool_drvinfo *info)
1718 {
1719 strcpy(info->driver, driver_name);
1720 strcpy(info->bus_info, "ieee1394"); /* FIXME provide more detail? */
1721 }
1722
Files
| reprod.tgz (2.4 MB) reprod.tgz | reproduce package for mem_ref and reference_type | Pavel Shved, 06/13/2011 06:45 PM |
Updated by Pavel Shved about 13 years ago
There are only 7 drivers affected. Not that important, I guess.
Updated by Evgeny Novikov almost 13 years ago
- Status changed from New to Open
As I understand just mem_ref tree node isn't supported at the moment.
Updated by Evgeny Novikov almost 13 years ago
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.
Updated by Alexey Khoroshilov almost 13 years ago
- Priority changed from Normal to High
ldv-git shows that only 10% of drivers reach RCV stage with the new aspectator. The main problems are:
reference_type - 80% fails
mem_ref - 46% fails
Updated by Evgeny Novikov almost 13 years ago
- Status changed from Open to Feedback
Alexey could you provide description of reference_type problem since I have never seen it...
Updated by Alexey Khoroshilov almost 13 years ago
- Status changed from Feedback to New
Eugene Novikov wrote:
Alexey could you provide description of reference_type problem since I have never seen it...
I do not know what is it. I just see a column in stats server.
Updated by Alexey Khoroshilov almost 13 years ago
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
Updated by Evgeny Novikov almost 13 years ago
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
After all leads to mem_ref problem:
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
(here you can see an example having the given problem).
Temporary workaround turn on options intended for old llvm-based aspectator.
Updated by Alexey Khoroshilov almost 13 years ago
Is it difficult to fix in c-backend/aspectator?
Updated by Evgeny Novikov almost 13 years ago
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.
Updated by Evgeny Novikov almost 13 years ago
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).
Updated by Evgeny Novikov almost 13 years ago
- Status changed from New to Open
The problem is clear. Work to eliminate it.
Updated by Pavel Shved almost 13 years ago
- File reprod.tgz reprod.tgz added
I prepared a package to easily reproduce both bugs. But the strange thing is that one of them reproduces on Alexey's machine only! Does it have something to do with 32-bit arch?
Steps to reproduce:
Download Linux Kernel 3.0-rc1, unpack it and prepare
mkdir -p /tmp/reproduce_kernel tar -xaf linux-3.0-rc1.tar.bz2 -C /tmp/reproduce_kernel cd /tmp/reproduce_kernel/linux-3.0-rc1/ make allmodconfig && make init
Delete line 822 in file /tmp/reproduce_kernel/linux-3.0-rc1/include/linux/rcupdate.h (or build will be failing with message about negative array size)
Download reprod.tgz and unpack it:
tar -xaf reprod.tgz -C /
Adjust <opt> in /tmp/reproduce/*/cmd.xml to point to GCC includes.
Now you can launch rule instrumentor:
LDV_DEBUG=100 WORK_DIR=`pwd` rule-instrumentor.pl --basedir=/tmp/reproduce/ref_type/driver --rule-model=43_1a --cmdfile=/tmp/reproduce/ref_type/cmd.xml --cmdfile-out=out.xml
or mem_ref/cmd.xml for the other bug.
There's a prepared version of these tools at tester@falcon in the ~/shved_tmp_bug1165. change dir there and launch ./fail.sh.
Updated by Evgeny Novikov almost 13 years ago
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));
}
that in turn leads to generation of reference type in C in gcc/c-family/c-common.c:
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);
}
...
}
So, when C backend prints calls to (for instance)
__builtin_va_start function it should insert cast to reference type but it cannot do this:__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 );
Updated by Evgeny Novikov almost 13 years ago
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,memcpyand a lot of others to gcc builtin functions (__builtin_strcpy,__builtin_memcpyand so on). Moreover, it leaded to total absence of MEM_REF.
The fix is available in master commit:b542cb99e
Updated by Evgeny Novikov almost 13 years ago
- Status changed from Open to Resolved
- Published in build set to 301fbf8
After yesterday discussion we decided to overcome the problem with reference type arising at x86 architecture in functions like __builtin_va_start simply by ignoring it. So at the moment we obtain uncompilable but checkable sources:
/tmp/reproduce/ref_type/driver/drivers/base/core.c.p: In function ‘dev_crit’: /tmp/reproduce/ref_type/driver/drivers/base/core.c.p:1830: error: incompatible type for argument 1 of ‘__builtin_va_start’ #‘reference_type’ not supported by pp_c_direct_abstract_declarator#’‘char ***’/tmp/reproduce/ref_type/driver/drivers/base/core.c.p:1830: note: expected but argument is of type
As for me, I don't know exactly how to deal with the given issue, but there is separate #1258 bug that covers it.
Updated by Alexey Khoroshilov almost 13 years ago
- Status changed from Resolved to Open
- Published in build deleted (
301fbf8)
After checking ~200 drivers it looks like reference_type issue is fixed, while mem_ref is still a significant one (~45% fails).
For example drivers/char/random.ko fails with the following message:
drivers/char/random.c.p: In function 'extract_entropy': drivers/char/random.c.p:902:1: error: LDV: ldv-pointcut-matcher.c: 310: tree node 'mem_ref' isn't supported drivers/char/random.c.p:902:1: error: LDV: ldv-pointcut-matcher.c: 310: tree node 'mem_ref' isn't supported
Updated by Pavel Shved almost 13 years ago
I do not see any memref errors on my machine. Perhaps, it's the x86 issue again.
Updated by Evgeny Novikov almost 13 years ago
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
So I suggest that we should also prevent
__builtin_* functions changes (that in particular leads to MEM_REF) or I can try to implement MEM_REF processing by returning back a call to __builtin_ function. I think that the first way is preferable since the second may be doesn't give the initial representation...Updated by Evgeny Novikov almost 13 years ago
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);
}
But I don't know exactly the field of mapped to MEM_REF constructions and I suggest that the easiest way to fix it is to disable so called built-in functions folding just in aspectator mode of gcc.
Updated by Evgeny Novikov almost 13 years ago
- Status changed from Open to Resolved
After a couple of attempts it becomes clear that folding should be ignored just for those built-in functions that leads to MEM_REF. It's interesting that just functions mem{{,p}cpy,move} contain the given "problem". So, eventually I have disabled these functions folding just in C source code generation (that's why object code will be the same as earlier). It's under test now.
Updated by Pavel Shved almost 13 years ago
So the generated code will just contain "memcpy" calls et al, and won't unroll it into built-in functions?
Updated by Evgeny Novikov almost 13 years ago
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).
Updated by Evgeny Novikov almost 13 years ago
- Status changed from Resolved to Open
Unfortunately, it is not enough just to disable folding in C backend since aspectator also doesn't like MEM_REF. So at the moment I disable these functions folding in both tools.
Updated by Evgeny Novikov almost 13 years ago
- Status changed from Open to Resolved
- Published in build set to d8d3c5a
At last, it seems that the problem was fixed. The issue should be closed after huge testing with git.
Updated by Alexey Khoroshilov almost 13 years ago
- Status changed from Resolved to Closed
I do not see mem_ref problems anymore.
Updated by Evgeny Novikov over 11 years ago
- Project changed from Linux Driver Verification to C Instrumentation Framework
- Category deleted (
15)