«

W dniu czwartek, 10 stycznia 2013 15:37:45 UTC+1 użytkownik Ben Bacarisse napisał:
> writes:
>
>
>
> > Ok, after long investigation I have successfully prepared simple C
>
> > program that illustrates the issue:
>
> > 3 files:
>
> > - bar.h
>
> > - bar.c
>
> > - main.c
>
>
>
> A data point: your example compiles and runs clean with gcc 4.7.2 and
>
> mudflap 4.7.
>
>

Thanks for information.
I'm going to update my system with newer GCC+MUDFLAP.

--
Maciek

On 1/10/2013 09:48, wrote:
> 02: mudflap violation 1 (register): time=1357829219.568594 ptr=0xbfd9f6b8 size=72
> 03: pc=0xb762b85e
> 04: /usr/lib/i386-linux-gnu/libmudflap.so.0(__mf_register+0x3e) [0xb762b85e]
> 05: ./a.out() [0x8048979]
> 06: ./a.out() [0x80489e2]
> 07: Nearby object 1: checked region begins 8B into and ends 79B into
> 08: mudflap object 0x9a021e8: name=`constant'
> 09: bounds=[0xbfd9f6b0,0xbfd9f6ff] size=80 area=static check=0r/0w liveness=0
> 10: alloc time=1357829219.568588 pc=0xb762b85e
> 11: number of nearby objects: 1
> 12: mf: alloca stack level 0xbfd9f5a8

Oops. Missed 'alloca', before. I'd guess that it has a bug. If you
change your arrays to 'static' storage duration, perhaps the problem
would disappear, as 'alloca' wouldn't be used. - Shao

> > A data point: your example compiles and runs clean with gcc 4.7.2 and
>
> >
>
> > mudflap 4.7.

Upgraded GCC to 4.7:
Linux ldrlinux 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux
gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
libmudflap0-4.7-dev

Issue is still present - today I'm giving up

--
Maciek

writes:

>> > A data point: your example compiles and runs clean with gcc 4.7.2 and
>>
>> >
>>
>> > mudflap 4.7.
>
> Upgraded GCC to 4.7:
> Linux ldrlinux 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux
> gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
> libmudflap0-4.7-dev
>
> Issue is still present - today I'm giving up

Just to confirm:

$ gcc -ansi -pedantic -Wall -W -Werror -fmudflap bar.c main.c -lmudflap
$ ./a.out
Hello World !
foo_fun = 234930176
bar_fun = 1564
$ gcc --version
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
Copyright © 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ dpkg -s libmudflap0
Package: libmudflap0
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 270
Maintainer: Ubuntu Core developers <ubuntu-devel->
Architecture: amd64
Multi-Arch: same
Source: gcc-4.7
Version: 4.7.2-2ubuntu1
Depends: gcc-4.7-base (= 4.7.2-2ubuntu1), libc6 (>= 2.14)
Pre-Depends: multiarch-support
Breaks: gcc-4.1, gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2)
Description: GCC mudflap shared support libraries
The libmudflap libraries are used by GCC for instrumenting pointer and array
dereferencing operations.
Homepage: http://gcc.gnu.org/
Original-Maintainer: Debian GCC Maintainers <debian->
$ uname -a
Linux tinky 3.5.0-21-generic-tuxonice #32~ppa1-Ubuntu SMP Tue Dec 18 20:29:04 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

--
Ben.

On 1/10/2013 10:41, wrote:
>>> A data point: your example compiles and runs clean with gcc 4.7.2 and
>>
>>>
>>
>>> mudflap 4.7.
>
> Upgraded GCC to 4.7:
> Linux ldrlinux 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux
> gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
> libmudflap0-4.7-dev
>
> Issue is still present - today I'm giving up
>

I was unable to reproduce the violations with:
- gcc version 4.7.2 20120921 (Red Hat 4.7.2-2)
- libmudflap 4.7.2, release 2.fc17

- Shao Miller

I have executed this test on UBUNTU 12.04 on 64 bit machine and issue is not present.

BUT, after change the type of the elemnt array from int(4bytes) to long(8bytes) issue comes back:

--------------------------
+ uname -a
Linux qa-stream-server 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
+ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ dpkg -s libmudflap0
Package: libmudflap0
Status: install ok installed
Multi-Arch: same
Priority: optional
Section: libs
Installed-Size: 266
Maintainer: Ubuntu Core developers <ubuntu-devel->
Architecture: amd64
Source: gcc-4.6
Version: 4.6.3-1ubuntu5
Depends: gcc-4.6-base (= 4.6.3-1ubuntu5), libc6 (>= 2.14)
Pre-Depends: multiarch-support
Breaks: gcc-4.1, gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2)
Description: GCC mudflap shared support libraries
The libmudflap libraries are used by GCC for instrumenting pointer and array
dereferencing operations.
Homepage: http://gcc.gnu.org/
Original-Maintainer: Debian GCC Maintainers <debian->
+ gawk '{printf("%02u: %s\n", NR, $0);}' bar.h
01: int bar_fun(unsigned idx);
02: #define ARRAY_NO_OF_ELEMENTS(a) ((unsigned)(sizeof(a) / sizeof(*a)))
+ gawk '{printf("%02u: %s\n", NR, $0);}' bar.c
01: #include "bar.h"
02: int bar_fun(unsigned idx)
03: {
04: long bar_cfg [][2] =
05: {
06: {9, 0},
07: {8, 1},
08: {7, 2},
09: {6, 3},
10: {5, 4},
11: {4, 5},
12: {3, 6},
13: {2, 7},
14: #ifdef WORKAROUND_FOR_MUDFLAP
15: {1, 8},
16: #endif
17: {0, 9}
18: };
19: return (idx < ARRAY_NO_OF_ELEMENTS(bar_cfg)) ? (int)(bar_cfg[idx][1]) : -1;
20: }
+ gawk '{printf("%02u: %s\n", NR, $0);}' main.c
01: #include <stdio.h> /* printf */
02: #include <stdlib.h> /* EXIT_SUCCESS */
03: #include "bar.h"
04: static int foo_fun(unsigned idx)
05: {
06: long const TOSTEP [][2] =
07: {
08: {0, 9},
09: {1, 8},
10: {2, 7},
11: {3, 6},
12: {4, 5},
13: {5, 4},
14: {6, 3},
15: {7, 2},
16: {8, 1},
17: {9, 0}
18: };
19: return (idx < ARRAY_NO_OF_ELEMENTS(TOSTEP)) ? (int)(TOSTEP[idx][1]) : -1;
20: }
21: int main(void)
22: {
23: printf("Hello World ! (c=%u,s=%u,i=%u,l=%u,p=%u)\r\n", \
24: (unsigned)sizeof(char), (unsigned)sizeof(short), \
25: (unsigned)sizeof(int), (unsigned)sizeof(long), \
26: (unsigned)sizeof(void *));
27: printf("foo_fun = %d\r\n", foo_fun(4));
28: printf("bar_fun = %d\r\n", bar_fun(4));
29: return EXIT_SUCCESS;
30: }
+ export 'MUDFLAP_OPTIONS=-mode-check -viol-nop -verbose-trace -internal-checking -print-leaks -check-initialization -verbose-violations'
+ MUDFLAP_OPTIONS='-mode-check -viol-nop -verbose-trace -internal-checking -print-leaks -check-initialization -verbose-violations'
+ gcc -ggdb -g3 -ansi -pedantic -Wall -W -Werror -fmudflap bar.c main.c -lmudflap
+ ./a.out
+ gawk '{printf("%02u: %s\n", NR, $0);}'
01: *******
02: mudflap violation 1 (register): time=1357902146.588238 ptr=0x7fff9312cfd0 size=160
03: pc=0x7ff09ad05291
04: /usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_register+0x41) [0x7ff09ad05291]
05: ./a.out() [0x400d0f]
06: ./a.out(__libc_csu_init+0x5d) [0x400dbd]
07: Nearby object 1: checked region begins 16B before and ends 143B into
08: mudflap object 0x22d6370: name=`constant'
09: bounds=[0x7fff9312cfe0,0x7fff9312d06f] size=144 area=static check=0r/0w liveness=0
10: alloc time=1357902146.588237 pc=0x7ff09ad05291
11: number of nearby objects: 1
12: mf: alloca stack level 0x7fff9312cf20
13: Hello World ! (c=1,s=2,i=4,l=8,p=
14: foo_fun = 5
15: bar_fun = 4
16: *******
17: mudflap violation 2 (unregister): time=1357902146.588445 ptr=0x22d6970 size=0
18: pc=0x7ff09ad04e36
19: number of nearby objects: 0
20: number of leaked objects: 0
+ gcc -ggdb -g3 -ansi -pedantic -Wall -W -Werror -fmudflap -DWORKAROUND_FOR_MUDFLAP bar.c main.c -lmudflap
+ ./a.out
+ gawk '{printf("%02u: %s\n", NR, $0);}'
01: mf: harmless duplicate reg 0x7fff7ffebcc0-0x7fff7ffebd5f `constant'
02: mf: alloca stack level 0x7fff7ffebc20
03: Hello World ! (c=1,s=2,i=4,l=8,p=
04: foo_fun = 5
05: bar_fun = 4
06: number of leaked objects: 0
--------------------------

I'm going to check that issue on GCC 4.7.

--
Maciek

W dniu piątek, 11 stycznia 2013 12:03:51 UTC+1 użytkownik m.laba....@gmail.com napisał:
> I have executed this test on UBUNTU 12.04 on 64 bit machine and issue is not present.
> BUT, after change the type of the elemnt array from int(4bytes) to long(8bytes) issue comes back:
>
....
>
> I'm going to check that issue on GCC 4.7.
>

GCC 4.7 (64bitMachine) issue still present:
$ uname -a
Linux qa-stream-server 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ dpkg -s libmudflap0
Package: libmudflap0
Status: install ok installed
Multi-Arch: same
Priority: optional
Section: libs
Installed-Size: 270
Maintainer: Ubuntu Core developers <ubuntu-devel->
Architecture: amd64
Source: gcc-4.7
Version: 4.7.2-11precise2
Depends: gcc-4.7-base (= 4.7.2-11precise2), libc6 (>= 2.14)
Pre-Depends: multiarch-support
Breaks: gcc-4.1, gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2)
Description: GCC mudflap shared support libraries
The libmudflap libraries are used by GCC for instrumenting pointer and array
dereferencing operations.
Homepage: http://gcc.gnu.org/
Original-Maintainer: Debian GCC Maintainers <debian->

--
Maciek

On 01/11/2013 07:14 AM, wrote:
[more on problems with gcc -mudflap]

I'm curious - why haven't you followed up yet on my suggestion that you
take this question to a gcc forum, such as gnu.gcc.help, where you're
likely to get better answers to your question?

Also, see <http://gcc.gnu.org/bugs/>. <http://gcc.gnu.org/bugzilla/>
lists 64 open bugs containing the word "mudflap". I'd recommend checking
whether any of those bugs matches your problem, before filing a new one.

--
James Kuyper

Shao Miller <> writes:
[...]
> MUDFLAP can diagnose stuff that's permitted by C90, such as warning you
> that an index used for iteration has gone too far. Usually you want to
> index one-past an array, at most. Do the 'for' loops have any problems?

As I'm sure you know, it's legal to construct a pointer one element
past the end of an array, but not to dererence it. Constructing a
pointer before the beginning of an array or more than one element
past the end of it, or deferencing a pointer one past the end of it,
has undefined behavior. I'm not aware of any relevant changes in
this area from C90 to C99 to C11.

Are you saying that Mudflap complains about stuff that's legal *and
has defined behavior* in C90? If it complained about something
like this:

int arr[N];
int *ptr;
for (ptr = arr; ptr < arr + N; ptr ++) {
/* ... */
}

that would IMHO be a serious bug in Mudflap.

(I haven't analyzed the posted code, but from the discussion I don't
think that's what's going on.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 1/11/2013 11:19, Keith Thompson wrote:
> Shao Miller <> writes:
> [...]
>> MUDFLAP can diagnose stuff that's permitted by C90, such as warning you
>> that an index used for iteration has gone too far. Usually you want to
>> index one-past an array, at most. Do the 'for' loops have any problems?
>
> As I'm sure you know, it's legal to construct a pointer one element
> past the end of an array, but not to dererence it. Constructing a
> pointer before the beginning of an array or more than one element
> past the end of it, or deferencing a pointer one past the end of it,
> has undefined behavior. I'm not aware of any relevant changes in
> this area from C90 to C99 to C11.
>
> Are you saying that Mudflap complains about stuff that's legal *and
> has defined behavior* in C90? If it complained about something
> like this:
>
> int arr[N];
> int *ptr;
> for (ptr = arr; ptr < arr + N; ptr ++) {
> /* ... */
> }
>
> that would IMHO be a serious bug in Mudflap.
>
> (I haven't analyzed the posted code, but from the discussion I don't
> think that's what's going on.)
>

Nah, I tried to be careful and chose to type "index" instead of "point".
The code I was criticizing used both an integer index as well as a
pointer. Their pointer would never point more than one past the array,
but their integer would index two past the array. That seems to be
permitted by C90.

I seem to recall some bit about this situation being easily detectable
and reportable as a bonus diagnostic, perhaps in the hopes of alerting
the programmer that there's a better way to write their loop without
stepping out of bounds, conceptually.

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter