Date: Fri, 1 Feb 2002 20:43:54 +0200 (SAT) From: John Hay <jhay@icomtek.csir.co.za> To: obrien@FreeBSD.org Cc: jhay@icomtek.csir.co.za (John Hay), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/contrib/binutils Message-ID: <200202011843.g11Ihsj66783@zibbi.icomtek.csir.co.za> In-Reply-To: <20020201092554.A52827@dragon.nuxi.com> from "David O'Brien" at "Feb 1, 2002 09:25:54 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, Jan 31, 2002 at 06:30:23AM +0200, John Hay wrote:
> > > I need nothing. It is a question of what you or the port maintainer
> > > needs.
> >
> > You are right I can't force you to do anything. For now I'll just build
> > -current release snapshosts with NODOC specified like the other two
> > snap building machines does.
>
> It would be nice if others would help out with the debugging. The
> problem probably isn't something that I am an expert on more than many
> others. You showed gdb output from stripped binaries, so the output was
> not very useful.
>
> When building those ports, do you get any new usual warnings?
The problem seems to be something with libpng. A program dynamically linked
with libpng crash while ld-elf.so.1 is still trying to link the libraries.
The easiest way to reproduce it, that I have found so far is the following:
Delete the png package if it is already installed.
#########################
cd /usr/ports/graphics/png
make install
cd work/libpng
make -f scripts/makefile.std pngtest.o PORTOBJFORMAT=elf ARCH=i386
cc -o pngtest pngtest.o -L/usr/local/lib -lpng -lz -lm
./pngtest
############################
Because the problem seems to be during dynamic linking and not really the
execution of the program, I have only built ld-elf.so.1 with debugging.
This is what I see in gdb:
########################
gdb ./pngtest ./pngtest.core
...
Core was generated by `pngtest'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/local/lib/libpng.so.5...
(no debugging symbols found)...done.
Reading symbols from /usr/lib/libz.so.2...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libc.so.5...(no debugging symbols found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...Deprecated bfd_read called at /home/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dwarf2read.c line 3049 in dwarf2_read_section
done.
#0 0x2805353a in reloc_non_plt (obj=0x0, obj_rtld=0x0)
at /home/src/libexec/rtld-elf/i386/reloc.c:196
196 *where += (Elf_Addr) obj->relocbase;
(gdb) bt
#0 0x2805353a in reloc_non_plt (obj=0x0, obj_rtld=0x0)
at /home/src/libexec/rtld-elf/i386/reloc.c:196
#1 0x28050f70 in relocate_objects (first=0x0, bind_now=0 '\000')
at /home/src/libexec/rtld-elf/rtld.c:1397
#2 0x2804f9f0 in _rtld (sp=0x28066100, exit_proc=0x2806c000, objp=0x2806c000)
at /home/src/libexec/rtld-elf/rtld.c:379
(gdb) print obj
$1 = (struct Struct_Obj_Entry *) 0x0
(gdb)
#############################
It seems as if the stack or something gets clobbered in reloc_non_plt()
because obj has been used earlier in the function and didn't cause a bus
error then.
This is where I got stuck. :-)
John
--
John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202011843.g11Ihsj66783>