|
From: xinglp <xi...@gm...> - 2011-02-15 14:23:22
|
There are several 4M+ files under <prefix>/lib/valgrind. How about create a libcoregrind-<platform>.so instead of libcoregrind-<platform>.a, and make the huge files link to it. I've tried manually edit the Makefile.am,but failed. I can do the "move to shared lib job" on many sources (just add -fpic to CFLAGS and edit the Makefile.am),such as gdb ssh. It seems like the valgrind was complied and linked in a different way, so , how to get it work. Thanks for a hint. |
|
From: John R. <jr...@bi...> - 2011-02-15 15:03:09
|
xinglp wrote: > There are several 4M+ files under <prefix>/lib/valgrind. What specific problem does this cause? > How about create a libcoregrind-<platform>.so instead of > libcoregrind-<platform>.a, and make the huge files link to it. What explicit benefits do you expect from such a change? -- |
|
From: xinglp <xi...@gm...> - 2011-02-16 02:35:02
|
2011/2/15 John Reiser <jr...@bi...>: > xinglp wrote: >> There are several 4M+ files under <prefix>/lib/valgrind. > > What specific problem does this cause? > >> How about create a libcoregrind-<platform>.so instead of >> libcoregrind-<platform>.a, and make the huge files link to it. > > What explicit benefits do you expect from such a change? > 2011/2/16 Julian Seward <js...@ac...>: > The use of static linking is a design decision. It makes Valgrind > more stable and easier to port and test. This means the use of > shared libs is not on the agenda. in /usr/lib/valgrind 4.4M memcheck-amd64-linux 4.3M callgrind-amd64-linux 4.3M helgrind-amd64-linux 4.3M drd-amd64-linux 4.3M exp-ptrcheck-amd64-linux 4.2M cachegrind-amd64-linux 4.2M massif-amd64-linux 4.2M exp-dhat-amd64-linux 4.2M lackey-amd64-linux 4.2M exp-bbv-amd64-linux 4.2M none-amd64-linux in complie directory 11M ./VEX/libvex-amd64-linux.a 6.3M ./coregrind/libcoregrind-amd64-linux.a If those files were shared linked, the valgrind-bin-pkg will reduce its size by about 40M (80%) This is the benefit. |
|
From: Julian S. <js...@ac...> - 2011-02-15 17:02:04
|
On Tuesday, February 15, 2011, xinglp wrote: > There are several 4M+ files under <prefix>/lib/valgrind. > How about create a libcoregrind-<platform>.so instead of > libcoregrind-<platform>.a, and make the huge files link to it. The use of static linking is a design decision. It makes Valgrind more stable and easier to port and test. This means the use of shared libs is not on the agenda. J |
|
From: xinglp <xi...@gm...> - 2013-11-24 04:48:01
|
Maybe I find another way to reduce it's size without affect "more stable and
easier to port and test".
Since they have a lot common code and lite special code, we can change their
"int main()" to "int main_xxxx()" , compile them all together to a singler
executable file with the following code.
#include <stdio.h>
#include <string.h>
extern int main_memcheck(int argc, char **argv);
extern int main_none(int argc, char **argv);
// more items ...
static struct {
const char *name;
int (*func)(int argc, char **argv);
} multicall[] = {
{ "memcheck", main_memcheck},
{ "none", main_none},
// more items ...
};
#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
int main(int argc, char **argv)
{
int i;
for (i = 0; i < ARRAY_SIZE(multicall); i++) {
if (!strcmp(argv[0], multicall[i].name))
return multicall[i].func(argc, argv);
}
fprintf(stderr, "Invalid multicall command, available commands:");
for (i = 0; i < ARRAY_SIZE(multicall); i++)
fprintf(stderr, " %s", multicall[i].name);
fprintf(stderr, "\n");
return 1;
}
This is what busybox did. I have tried to a patch for valgrind before this
post, but unfortunately I failed again.
The source code struct of valgrind is not like others, event the simple
methods above isn't a easy work for me.
But that maybe easy for you.
Best wish.
xinglp
--
View this message in context: http://valgrind.10908.n7.nabble.com/Is-there-any-way-to-redues-the-valgrind-s-size-by-use-shared-lib-tp13836p47923.html
Sent from the Valgrind - Dev mailing list archive at Nabble.com.
|