[cfe-users] How can I hook malloc on iOS?

[Michael Eisel via cfe-users]

Hi,

I'd like to hook malloc for an iOS app in order to use a custom allocator
(jemalloc) that I have benchmarked and seen that it improves my app's
performance. I know there must be a way to hook malloc, since the address
sanitizer does it. Here are some possible routes:

- Do whatever the address sanitizer does to wrap malloc. However, it's hard
for me to figure out what's going on from the source code
- Swap out the function pointers of the default malloc zone for my own,
except that this is not safe
- Use the zone manipulation in
https://github.com/jemalloc/jemalloc/blob/dev/src/zone.c, except that this
appears to have only been written with OS X in mind
- Use CFAllocatorSetDefault, except that this seems to negate the speed
wins that I see and will not cover cases where a library is using malloc
rather than CFAllocatorAllocate
- Use interposing to swap the functions early on, except that it doesn't
seem to come soon enough to catch all mallocs, and the custom allocator
crashes when it's told to free something allocated with the original malloc

Does anyone have any ideas?

Thanks,
Michael
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

[cfe-users] MSVC always trying to rebuild project while using clang-cl (LLVM-vs2014 toolset)

[Aleksei via cfe-users]

Hello everyone,

 

I don’t know if I’ve found a bug in clang-cl using Visual Studio 2015, or it’s 
a quite normal behavior… It would be nice if someone clarify it and (better) 
fix something in clang-cl, because the current behavior is IMHO very confusing.

 

Background: Visual Studio 2015, version 14.0.25431.01 Update 3, LLVM version 
6.0.1 for win64

 

So, the problem is MSVC (under some condition) would always require to rebuild 
a project that has to be built with LLVM-vs2014 toolset, even if it’d just 
finished last rebuild.

 

The root cause of it in the absence of a file, that is specified under 
“Configuration Properties / C/C++ / Output Files / Program Database File Name” 
(typically, it’s filled with macro “$(IntDir)vc$(PlatformToolsetVersion).pdb” 
that expands to something similar to “x64\Debug\vc140.pdb”). I might be wrong 
in general case, but in my case this file is not generated by clang-cl at all 
during build process, it’s generated only by VC’s native compiler. So, should 
one delete it intentionally during manual cleanup or by an accident, MSVC would 
start to always require a full project rebuild before each run/debug.

 

It’s very easy to reproduce the problem: create a new Win32 console project in 
MSVC, then immediately change the toolset used to build the project to 
LLVM-vs2015 and then build the project (don’t build the project with native 
compiler before this step). Then run it and notice that MSVC would require the 
project to be rebuild.

Now, if one to switch back the toolset to VC’s native, build the project (to 
produce corresponding .pdb file), then switch the toolset to LLVM again and 
then build it and after that run it – MSVC would start the program immediately.

 

If the .pdb file is not required to run/debug a project, I guess it would be 
much better if clang-cl to emit some kind of warning/information during 
compilation about that fact. I’ve just wasted about 3-4 hours to find out why 
VC requires project rebuilding all the time…

 

Thanks.

 

Sincerely,

Aleksei

 

 

___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users