Project

General

Profile

Actions
Copy link

Bug #1158

closed

GCC-aspectator re-defines integers instead of export

Added by Pavel Shved over 13 years ago. Updated about 12 years ago.

Status:
Closed
Priority:
High
Assignee:
Evgeny Novikov
Category:
-
Start date:
05/03/2011
Due date:
% Done:

0%

Estimated time:
Detected in build:
svn
Platform:
Published in build:
4ec46d7 model-43_1a

Description

Steps to reproduce:

LDV_DEBUG=30 ldv-manager rule_models=32_1a "envs=linux-2.6.31.6.tar.bz2" drivers=drivers/hid/hid.ko kernel_driver=1 name=ri03

Let's check the file work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/cmdfiles/rcv/32_1a/preprocessed/drivers-hid-hid-core.o.general.i

# 56 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
int hid_debug = 0;
static inline int *__check_debug(void)
{
# 57 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
  return & hid_debug;
}
# 57 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
static int __param_perm_check_debug = 0;
# 57 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
static char const __param_str_debug[6U] = "debug";
# 57 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
static struct kernel_param const __param_debug = { . name = ( char const *) & __param_str_debug , . perm = 384U , . flags = 0U , . set = & param_set_int , . get = & param_get_int , . ldv_9522 = { . arg = ( void *) & hid_debug } };
# 57 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
static char const __mod_debugtype57[19U] = "parmtype=debug:int";
static char const __mod_debug58[76U] = "parm=debug:HID debugging (0=off, 1=probing info, 2=continuous data dumping)";
# 56 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
int hid_debug = 0;
# 59 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
extern void *__crc_hid_debug;
# 59 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
static long unsigned int const __kcrctab_hid_debug = ( long unsigned int ) & __crc_hid_debug;
# 59 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
static char const __kstrtab_hid_debug[10U] = "hid_debug";
# 59 "/home/pavel/work/ldv/test/work/current--X--drivers/hid/hid.ko--X--ri03linux-2.6.31.6--X--32_1a/linux-2.6.31.6/csd_deg_dscv/17/dscv_tempdir/dscv/ri/32_1a/drivers/hid/hid-core.c.p" 
static struct kernel_symbol const __ksymtab_hid_debug = { . value = ( long unsigned int ) & hid_debug , . name = ( char const *) & __kstrtab_hid_debug };

We see two int hid_debug here, and BLAST doesn't like redefinition of global variables (let alone it's not a compilable C code). What makes me think it's an aspectator's error are not monotonic line numbers: 56-57-56-59.

Related issues 2 (1 open — 1 closed)

Related to Linux Driver Verification - Bug #1167: Bugs related with 32_1a modelOpen05/03/2011

Actions
Related to C Instrumentation Framework - Bug #1160: New aspectator doesn't convert abs() function properlyClosedEvgeny Novikov05/03/2011

Actions
Actions
Copy link
 #1

Updated by Pavel Shved over 13 years ago

  • Priority changed from Normal to High

There are 84 (!) drivers that are affected by this bug.

Raising priority, since it made test launch miss at least three Unsafes (maybe false, though), and appears in different subsystems of the kernel. Perhaps, we should even fix it in this sprint.

Actions
Copy link
 #2

Updated by Evgeny Novikov over 13 years ago

  • Status changed from New to Open

I'm going to estimate the complexity of the problem.

Actions
Copy link
 #3

Updated by Evgeny Novikov over 13 years ago

  • Subject changed from GCC-aspectator re-defines integers instead of export (?) to GCC-aspectator re-defines integers instead of export
  • Priority changed from High to Normal

Yes, there is such the problem, but, as we have investigated with Pavel, in fact it doesn't lead to fail. The main reason (at least for the described driver) is #1160. I go there.

Actions
Copy link
 #4

Updated by Pavel Shved over 13 years ago

Try drivers/usb/storage/usb-storage.ko . It seems to only have this kind of error, and BLAST ends up with a parsing error anyway.

Actions
Copy link
 #5

Updated by Pavel Shved over 13 years ago

  • Priority changed from Normal to High
Actions
Copy link
 #6

Updated by Evgeny Novikov over 13 years ago

Begin to implement following solution: remember all printed global variable names and don't print (may be add extern and remove initializer) other global variables with the same name.
As for functions their prototypes were necessary even after their definitions since subsequent application of aspectator requires them to make compilable code as I remember.

Actions
Copy link
 #7

Updated by Alexey Khoroshilov over 13 years ago

Eugene Novikov wrote:

Begin to implement following solution: remember all printed global variable names and don't print (may be add extern and remove initializer) other global variables with the same name.

Is initializer always available in the first printed definition?

I worry a little bit about something like:

extern int v;
extern int v = 15;

Actions
Copy link
 #8

Updated by Evgeny Novikov over 13 years ago

Alexey Khoroshilov wrote:

Is initializer always available in the first printed definition?

I worry a little bit about something like:
[...]

Yes that's true! I have already mentioned that my approach isn't correct enough after implementation and testing. So I extend it with initialization requirement. So global variables aren't printed just when a global variable with the same name and that has initializer was printed before. And note, that

int a;
int a;
int a = 0;

doesn't cause any problem.

Actions
Copy link
 #9

Updated by Evgeny Novikov over 13 years ago

  • Status changed from Open to Resolved
  • Published in build set to 4ec46d7 model-43_1a

It was fixed and tested on drivers/hid that contained 2 of such bugs. At the moment there isn't such bugs.

Actions
Copy link
 #10

Updated by Evgeny Novikov over 13 years ago

All other drivers are also correct in this way.

Actions
Copy link
 #11

Updated by Pavel Shved over 13 years ago

  • Status changed from Resolved to Closed

Accepted on demo 16.

Actions
Copy link
 #12

Updated by Evgeny Novikov about 12 years ago

  • Project changed from Linux Driver Verification to C Instrumentation Framework
  • Category deleted (15)
Actions
Copy link

Also available in: Atom PDF