|
From: Naveen K. <g_n...@ya...> - 2005-01-16 05:38:22
|
Fixed it. I changed the interpreter for stage2 to
libc.so instead of ld.so. All executables by default
use ld.so and they work fine but the gcc exe itself
uses libc for some reason. So I decided to give that a
try and it worked. Dont know why hey stage2 is
starting. Now I get a
valgrind: Missing --tool option
Can't open /export/home/msat/my_local//lib/valgrind:
Not enough space (installation problem?)
valgrind: Use --help for more information.
The opendir is failing. A 'truss valgrind' showed this
......
open64("/export/home/msat/my_local//lib/valgrind",
O_RDONLY|O_NDELAY) = 7
fcntl(7, F_SETFD, 0x00000001) = 0
fstat64(7, 0x080479D4) = 0
brk(0x601DFB80) Err#12
ENOMEM
close(7) = 0
brk(0x601DFB80) Err#12
ENOMEM
..........
The address 0x601DFB80 is the stage2 elf brkbase. Due
to this(brk-ENOMEM) any malloc calls or other calls
that depend on it fail. Any pointers ???
Thanks
Naveen
--- Jeremy Fitzhardinge <je...@go...> wrote:
> On Fri, 2005-01-14 at 12:45 -0800, Naveen Kumar
> wrote:
> > -Wl,--export-dynamic to -static for stage2_LDFLAGS
> in
> > coregrind/Makefile.in
>
> You probably still need the -Wl,--export-dynamic,
> because that allows
> loaded .so files to see the public symbols. I'm
> guessing the reason
> you're still getting an ld.so reference is because
> of -ldl, which is
> necessary so that Valgrind can load a tool .so file.
> You might want to
> do a temporary hack and statically link nulgrind
> with stage2, and remove
> all the dlopen calls (hm, that could get fiddley
> with all the dlsym
> calls in there), and -ldl.
>
> > I compiled a simple hello world prog with the
> -static
> > option and it worked. In the above case it doesn't
> > seem to. This is the full command line
> >
> > gcc -D__SunOS__ -Winline -Wall -Wshadow -O
> > -fno-omit-frame-pointer
> -mpreferred-stack-boundary=2
> > -g -DELFSZ=32 -lsocket /usr/lib/libposix4.so -o
> > stage2 -static -Wl,-e,_ume_entry -g
> > -Wl,-defsym,kickstart_base=0x60000000
> > -Wl,-T,x86/stage2.lds -Wl,-version-script
> > ./valgrind.vs ume.o ume_entry.o ume_go.o
> > vg_scheduler.o vg_default.o vg_demangle.o
> > vg_dispatch.o vg_errcontext.o vg_execontext.o
> > vg_from_ucode.o vg_hashtable.o vg_helpers.o
> > vg_instrument.o vg_main.o vg_malloc2.o vg_memory.o
> > vg_messages.o vg_mylibc.o vg_needs.o
> vg_procselfmaps.o
> > vg_proxylwp.o vg_dummy_profile.o vg_signals.o
> > vg_symtab2.o vg_dwarf.o vg_stabs.o vg_skiplist.o
> > vg_symtypes.o vg_syscalls.o vg_syscall.o
> vg_to_ucode.o
> > vg_toolint.o vg_translate.o vg_transtab.o vg_ldt.o
> > vg_cpuid.o demangle/cp-demangle.o
> demangle/cplus-dem.o
> > demangle/dyn-string.o demangle/safe-ctype.o
>
> What version are you using? Are you tracking CVS?
> There doesn't seem
> to be enough in that link line; I would expect to
> see solaris/libos.a
> and x86-solaris/libplatform.a there.
>
> > There was a problem with the AUXV which made the
> > dynamic linker to crash. Basically the AUXV wasn't
> > positioned correctly. The culprit was in fix_auxv
> >
> > auxv -= delta/sizeof(*auxv);
> >
> > what happens if delta isn't a multiple of
> > sizeof(*auxv) ?
>
> I think Paul had the same problem with the PPC port.
> It does look
> wrong. Does "auxv -= new_entries" work?
>
> > I am going to see if I can
> > obtain the Solaris sources. Then this should make
> the
> > work easier.
>
> Yep.
>
> J
>
>
>
>
-------------------------------------------------------
> The SF.Net email is sponsored by: Beat the
> post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt
> from ThinkGeek.
> It's fun and FREE -- well,
> almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
>
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
|