Disabling special treatment of "malloc" function

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Disabling special treatment of "malloc" function

Chris Smowton
Hi,

I'm using uclibc built with dragonegg-3.2 / gcc-4.6, and ran into a
problem in which:

* uclibc's realloc malloc()'s some memory
* realloc then uses (malloc'd pointer) - some offset to find the true
size allocated.
* MemoryDependenceAnalysis (MDA) regards load from (malloc() call + any
offset) to be undefined, and replaces the size read with 0.
* All manner of chaos results when that value is used.

Obviously the problem is MDA assumes that load from malloc without
intervening store is undefined, but that assumption is unreasonable when
you're building parts of the allocator itself. It looks like LLVM makes
a little effort to spot that situation (it won't enforce malloc's
contract if the malloc function has a definition), but from the point of
view of building the realloc call malloc is an external declaration just
like for a program using libc.

For now I've added a flag to MDA such that malloc clobbers rather than
resolving to undef; however I was wondering if there is a "proper" way
to do this with any compiler targeting LLVM?

If it's actually not solved already, I'd suggest that instead of
assuming "derived from malloc -> undef" it could be better to leave such
loads alone unless they are provably within the bounds of the allocation
- so malloc(n) yields n bytes of undef, but clobbers out of bounds
pointers derived from the same malloc.

Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Disabling special treatment of "malloc" function

Tim Northover-2
Hi Chris,

> For now I've added a flag to MDA such that malloc clobbers rather than
> resolving to undef; however I was wondering if there is a "proper" way to do
> this with any compiler targeting LLVM?

Clang has an option "-fno-builtin" that disables such assumptions (by
adding the attribute "nobuiltin" to the relevant callsites by the
looks of it). Is that useful to you?

Cheers.

Tim.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Disabling special treatment of "malloc" function

Chris Smowton
On 08/09/13 16:36, Tim Northover wrote:
>
>> For now I've added a flag to MDA such that malloc clobbers rather than
>> resolving to undef; however I was wondering if there is a "proper" way to do
>> this with any compiler targeting LLVM?
> Clang has an option "-fno-builtin" that disables such assumptions (by
> adding the attribute "nobuiltin" to the relevant callsites by the
> looks of it). Is that useful to you?
That works; unfortunately I was using Dragonegg and would rather not
switch at this point.

For the benefit of Googlers, it appears that Clang -fno-builtin leads to
a call to TargetLibraryInfo::disableAllFunctions, but Dragonegg-3.2
never calls it.

However Dragonegg-3.3 /does/ honour the GCC -fno-builtin flag (diff
here: http://llvm.org/viewvc/llvm-project?view=revision&revision=179666).

This is a little blunt for my purposes -- I only need to disable malloc
for this purpose, but it suffices.

(Side note: I hadn't realised a Dragonegg 3.3 release existed because
http://dragonegg.llvm.org/ is out of date)

Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Disabling special treatment of "malloc" function

Duncan Sands
Hi Chris,

> (Side note: I hadn't realised a Dragonegg 3.3 release existed because
> http://dragonegg.llvm.org/ is out of date)

sorry about that, I've updated the web-site.

Ciao, Duncan.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev