[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130616153117.GO29800@brightrain.aerifal.cx>
Date: Sun, 16 Jun 2013 11:31:17 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: valgrind problems
On Sun, Jun 16, 2013 at 05:26:19PM +0200, Jens Gustedt wrote:
> Hello,
>
> Am Sonntag, den 16.06.2013, 10:31 -0400 schrieb Rich Felker:
> > Is there no way to make the suppression more fine-grained? For
> > example, "ignore up to wordsize-1 sequential invalid reads in this
> > function" would give the desired behavior. glibc has some sort of
> > suppression for these functions; what does valgrind do for glibc?
>
> I think it basically wraps its own code around some functions. Or
> maybe just replaces them?
>
> Such an approach obviously doesn't work if we link the C library
> statically. I just wanted to try to link statically against glibc to
> see what happens, but got stuck with other stuff.
I see. Have you tried dynamic linking with musl?
> > > Also for calloc I am not sure that when we switch off the false
> > > positive (where musl assumes a certain gcc behavior for what in
> > > general is UB)
> >
> > musl is not assuming any gcc behavior.
>
> unfortunately it does. as an optimization shortcut it reads the newly
> allocated bytes and if they are already 0, it doesn't write to
> them.
This is not gcc behavior. It's behavior of it's own implementation of
malloc. From the implementation's standpoint, the object returned by
malloc does not have indeterminate value; otherwise it would be
impossible to link it with its bookkeeping information, contained in
the header of the object, and to later free it. In other words, if you
required the implementation to treat malloc as a black box, it would
be impossible to implement free.
> So this uses the fact that the newly allocated memory has an
> unspecified, but determined value to do some optimization.
>
> It is exactly that line of calloc.c, namely the `if` in line 20 that
> triggers under valgrind.
>
> In a recent discussion with the C committee I have learned that there
> is no consensus of whether an unspecified value is determined and
> wouldn't change once it is observed or whether it could be "wobbling"
> (the term that someone used, there). There are even people that
> propose to have a sort of state outside the object representation that
> captures if memory has been initialized or not.
This applies to applications but not to the implementation itself.
That's why musl is compiled with -ffreestanding: to tell the compiler
that functions with standard names are not black boxes it can assume
behave according to how they would on a hosted implementation, but
that we're implementing them.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
