search

DynamoRIO / dynamorio

Dynamic Instrumentation Tool Platform
Other
2.61k stars 554 forks source link

create syscall and module libc-independent utils lib for proper NOT_CORE_PROPER sharing, including with tests #1409

Open derekbruening opened 9 years ago

derekbruening commented 9 years ago

From bruen...@google.com on April 01, 2014 01:08:58

suite/tests/tools.c should share DR's raw syscalls: tools.c has a series of nolibc_*() routines and currently duplicates the asm routine dynamorio_syscall as nolibc_syscall. We should have a separate .asm file core/x86/syscall.asm that we can share.

Better to compile + link that one file in both dynamorio and test targets to avoid code duplication. We could additionally make it a static library to A) avoid duplicate compilation and B) ensure a clean interface.

While at it, split x86.asm and win32/ files to get rid of NOT_CORE_PROPER. Xref issue #1079 along with a lot of historic discussion but I don't think there was any issue filed until now.

Note that drfrontendlib pulls in module_{macho,elf}.c now, plus (the non-core-only part) of os.c, for os_open(), etc. drinjectlib is similar.

**\ TODO where put isolated utils?

Keep in core/ in general, as everything that goes into the core should be there.

Candidates:

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1409

derekbruening commented 9 years ago

From bruen...@google.com on April 15, 2014 15:22:37

issue #1035 is another case where a raw syscall lib would be useful

derekbruening commented 9 years ago

From bruen...@google.com on August 08, 2014 10:38:03

drfrontendlib apparently can't be used by itself: the frontend has to link with drinjectlib. missing syms include dynamo_options and dynamorio_syscall.

derekbruening commented 9 years ago

From bruen...@google.com on September 09, 2014 09:09:50

To clarify the prior comment: it's not drinjectlib itself, it's drdecodelib who provides dynamo_options and dynamorio_syscall. drinjectlib links with drdecodelib. drdecodelib has a special core/x86/decodelib.c file that resolves dynamo_options.

derekbruening commented 9 years ago

For #1737 I tried to switch drconfiglib and drinjectlib to be static, but on Windows it hit a number of problems documented there. This issue also covers properly splitting core/win32/{module,inject,ntdll}_shared.c into separate files so we can more easily build static libraries for both libutil and core.

derekbruening commented 6 years ago

Adding some work that wasn't referenced here:

Re: comments above about drfrontendlib pulling in dynamo_options and dynamorio_syscall and thus needing drdecodelib: we now have drhelper for dynamorio_syscall, and it looks to me like a quick fix is to put the option refs in module_elf.c under #ifndef NOT_DYNAMORIO_CORE_PROPER. (I'm revisiting this now b/c it's causing linking trouble making things like drcachesim standalone launchers for the opcode_mix tool.)

derekbruening commented 5 years ago

For #3348 we have a short-term goal of avoiding duplicate symbols when drfrontendlib and dynamorio are both linked into the same binary (as in opcode_mix_launcher) and --localize-hidden is removed. That coincides with the goals here.

The plan is to make a library out of the files double-compiled into drfrontendlib and dynamorio: os.c, module_{elf,macho}.c. I'm thinking of merging them with drhelper into a library "drlibc" ("libc" b/c it's a low-level utility library like the C library, but the "c" is really for "core"). Perhaps io.c and string.c could also be added there.

I would rename drhelper's core/arch//shared.asm to drlibc.asm and core/arch/asm_shared.asm to drlibc_xarch.asm: this is espousing the idea of not using the ambiguous "_shared" in favor of "_xarch" and "_xlib" (with the latter being phased out in favor of library name prefixes as separate libraries rather than separate compilation is used).

In the past there were votes for keeping the core dir structure and just using prefixes, so:

core/lib/drlibc.c core/lib/drlibc.h core/unix/drlibc_module_elf.c core/unix/drlibc_module_macho.c core/unix/drlibc_os.c core/arch/drlibc_xarch.asm core/arch/aarch64/drlibc_aarch64.asm core/arch/arm/drlibc_arm.asm core/arch/x86/drlibc_x86.asm (core/drlibc_io.c) (core/drlibc_string.c)

Keeping drlibc_module_elf.c next to moduleelf.c makes sense b/c they're both pieces of module interface. And having all arch-specific code in arch/ is logically nice. But it seems more important to group a library's files together: that should help to keep it more isolated. So:

core/drlibc/drlibc.c core/drlibc/drlibc.h core/drlibc/drlibc_module_elf.c core/drlibc/drlibc_module_macho.c core/drlibc/drlibc_unix.c core/drlibc/drlibc_xarch.asm core/drlibc/drlibc_aarch64.asm core/drlibc/drlibc_arm.asm core/drlibc/drlibc_x86.asm (core/drlibc/drlibc_io.c) (core/drlibc/drlibc_string.c)

Even in own subdir, leaving "drlibc_" prefix to avoid dup filenames in diff subdirs.

Windows would be tackled separately in the future: there is a lot more work there to disentangle the code. Presumably much of it would also move into core/drlibc and if there's enough it might be inside core/drlibc/win32/.

derekbruening commented 5 years ago

I'm using weak functions to support using LOG, ASSERT, etc. in drlibc code when linked into non-core binaries via drfrontendlib or drinjectlib while maintaining the core behavior. On Windows we have to separate conflicting syms into their own .obj files to make the MSVC linker not complain.