|
From: John C. <joh...@ta...> - 2003-12-23 01:47:12
|
Hmm. Linker, hmm, we're using the version of the GNU tool chain provided with ecos to build the apps. I forget the reason why, possibly because the standard gcc toolchain links to the a sharable version of libgcc.so (This is aimed at embedded apps that live in a device without so much as a loaded that can read elf executables let alone a dynamic linker.) I have attached a bzip2 version of the readelf -hls /usr/local/lib/valgrind/stage2 output. It is rather large. I'll try tomorrow, to use the standard linux toolchain and see what happens. On Mon, 22 Dec 2003, Jeremy Fitzhardinge wrote: > On Mon, 2003-12-22 at 16:42, John Carter wrote: > > Ok... > > > > 1) The reason why I'm using the bleeding edge Valgrind is I want to > > use the new Full Virtualization stuff that allows non-statically > > linked executables to be valgrinded. In particular ecos synthetic target > > executables. > > Yup, makes sense. I was thinking that static support would be useful > for this kind of thing. > > > 2) I have just tried Julian's suggested tweak to the linker script, it > > required one or two more tweaks to get it to link. It now links > > and run's outside of valgrind but under valgrind it says... > > > > valgrind -v --leak-check=yes ./MYPROG --io --nr --nw --exit > > Executable is mapped outside of range 0x80d3000-0xbffff000 > > failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory > > Ah, I think this we've chasing a red herring. The problem isn't your > executable; it's the linker you used to build Valgrind. What does > readelf -hls /usr/local/lib/valgrind/stage2 say? I'm guessing the > Makefile in coregrind/x86 has used the wrong version of "ld" to make > coregrind/x86/stage2.lds. > > J > John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : joh...@ta... New Zealand A Million Monkeys can inflict worse things than just Shakespeare on your system. |