Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Windows] Revisit how the RTL works in the presence of DLLs #209

Closed
ramosian-glider opened this issue Aug 31, 2015 · 7 comments
Closed

[Windows] Revisit how the RTL works in the presence of DLLs #209

ramosian-glider opened this issue Aug 31, 2015 · 7 comments
Labels
OpSys-Windows Priority-Medium ProjectAddressSanitizer Status-Fixed Type-Defect

Comments

@ramosian-glider
Copy link
Member

Originally reported on Google Code with ID 209

Some background.
[Feel free to correct me if you spot any mistakes]

Each DLL on Windows seems to have its own malloc/free/etc.
We do want to replace each malloc/free/etc with our own allocator in order to add redzones,
update shadow memory and support quarantine (1).
[We should probably warn if a memory allocated in one DLL gets deleted in another?]

We don't want to have a separate copy of the RTL in each DLL.
For example, mapping shadow memory and bookkeeping of thread-related info should be
shared between modules (2).

Various RTL functions from DLLs should be able to call the shared implementation in
the main module (3).
e.g.
- If a DLL executes its global ctors before the main module (can this happen?),
  we want it to call the shared __asan_init from the main module.
- Calling 'malloc' should call GET_STACK_TRACE_MALLOC (and hence
  some StackTrace methods) and 'asan_malloc'.

Reported by timurrrr@google.com on 2013-07-16 11:35:53
@ramosian-glider
Copy link
Member Author 

Re: (3) it might probably be enough to call
  GetProcAddress(GetModuleHandle(NULL), "__asan_foo")
from a DLL.
Hm, it might be not possible to lookup a function from the main module though. In this
case, we might want to put the "shared" stuff into an extra RTL DLL and link in a static
.lib replacing malloc/free/etc in the .exe and all the interesting .DLL

Thoughts?

Reported by timurrrr@google.com on 2013-07-16 11:41:24

@ramosian-glider
Copy link
Member Author 

Issue 104 has been merged into this issue.

Reported by timurrrr@google.com on 2013-07-16 11:43:45

@ramosian-glider
Copy link
Member Author 

Re: c#1 - yes it seems possible to call exe-functions from a DLL if they are exported.
http://john.nachtimwald.com/2012/07/15/calling-functions-in-exe-from-plugins-in-windows/

Reported by timurrrr@google.com on 2013-07-16 11:47:59

@ramosian-glider
Copy link
Member Author 

Yes, it is possible. Making __asan symbols always exported is reasonable solution.

Reported by dpolukhin@chromium.org on 2013-07-16 21:02:07

@ramosian-glider
Copy link
Member Author 

OK, so calling a dllexport function from an EXE is pretty straightforward and even a
bit simpler than described in the page mentioned in c#3.
The only issue is that if the RTL defines any dllexport functions, they EXE it links
in generates an auxillary .lib file which helps dllimport them. That's not a major
problem, other than some redundant .lib bloat in the build directories :)

It looks like we'll need to link the main executable with the RTL LIB, and link the
DLLs with a thunk LIB.
Hopefully, it won't be to hard to set up in Chromium GYP.

Reported by timurrrr@google.com on 2013-08-12 17:40:46

  • Status changed: Started

@ramosian-glider
Copy link
Member Author 

By using this simple .lib thunk
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/asan_dll_thunk.cc?revision=188278&view=markup
I'm now able to run the test from r1746 and get the expected report.

Marking this as Fixed as the general approach seems to work now.
Remaining things: add a few more tests, set up regular testing on the bot, test on
Chromium.

Reported by timurrrr@google.com on 2013-08-13 16:47:05

  • Status changed: Fixed

@ramosian-glider
Copy link
Member Author 

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:13:41

  • Labels added: ProjectAddressSanitizer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
OpSys-Windows Priority-Medium ProjectAddressSanitizer Status-Fixed Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ramosian-glider