|
From: Julian S. <js...@ac...> - 2005-06-28 10:11:55
|
Some time back in a thread "RFC: libc futures" (31 March 05) it
was suggested that statically linking the core to each tool would
possibly be beneficial. Recently I've been thinking a lot about
overhauling address space management, and as part of that I thought
I'd try the static linking game.
It's really not difficult. gcc needs -static, obviously, and
the magic incantations to set a non-default load address
(-Wl,-defsym,kickstart_base=0x70000000 -Wl,-T,../coregrind/stage2.lds),
load_tool() in m_main.c has to be turned into a no-op, more
or less, and the stuff in m_main that unmaps stage1's padding file
disappears. Once that's done I got a statically linked stage2+tool
combination that can be started directly; no need for stage1.
I checked that nulgrind and memcheck that work OK on both x86 and
amd64-linux.
So what are the advantages/disadvantages:
+ Simplicity: less code in m_main; stage1 disappears completely.
stage2 is started directly.
+ Independence: removes dependence on dlopen
+ Robustness: no need for huge mmaps, less likely to go wrong.
+ A big step towards build-time enforcement of no glibc use.
I've been experimenting with not only static linking but
also passing -nodefaultlibs -lgcc. This means glibc et al
are simply not linked in, and any use of a symbol not supplied
by V causes the link to fail. This doesn't work yet since we
make quite a lot of use of glibc, but I can see getting rid of
it is on the order of a day's work (apart from
localtime_r(), used for --time-stamp=yes).
- Disk space: usage increases since core is linked with every tool.
- External tools: installing eg Callgrind could be more complex as it
would have to be linked against libcoregrind.a at
installation time, even if installing from RPMs.
- PIE: this would make PIE'd valgrinds impossible. I'm not too
bothered since it seems like the main use for pie is to work
around the current address-space-layout inflexibilities, which
are up for review anyway.
- Need a replacement driver: since only one tool at a time is
linked into libcoregrind.a, the --tool= flag is ignored, and so
we'd need a new ultra-trivial driver which inspects that flag
and selects the right executable to start.
Alternatively, adjust the core/tool interface so that multiple
tools can be linked into the core all at once. This sounds
attractive, and could save disk space.
Comments? In particular, are there other bad consequences I haven't
thought of? Also, [GregP] how would this play for making V work
for MacOS ?
J
|