Jivin Jate Sujjavanich lays it down ... > I am getting the "lib 0 younger than lib 1" in the relocation code for the > reloc table for uClibc (shared lib 1). The code works until it reaches a > value of "0x00000001" which is interpreted as address 1 in library 0. Library > 0 is younger than 1, as it should be. > > Some of my theories are as follows. Maybe the linker is inserting a > 0x00000001 into the reloc table when it shouldn't be. Or maybe it should be, > and 0x00000001 is a new flag in the newer toolchain. > > I used objdump to look at the .rela.data section. The first entries to > strings made sense as additions of the data address, got length, offset and > addend. The next values in the reloc table do not match this pattern. > > Let me know if this rings any bells.
Just for reference, I don't think I know of anyone who has made shared libraries work with new toolchains. I would love someone to speak up if they have, but AFAIK something got broken in the msep-data/shared lib into newer compilers update, and only msep-data is working correctly. Cheers, Davidm > -----Original Message----- > From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] > Sent: Sun 7/29/2007 6:23 PM > To: uClinux development list > Subject: Re: [uClinux-dev] Shared library issues on m68knommu and gcc 4.1.1 > > I missed your initial message. I did the m68k shared library work so I ought > to understand this, although it was quite a few years ago now and memory > fades... > > > > My earlier understanding was incorrect. The problem (so far) is not in > > the GOT. It is definitely in the relocation table. > [...] > > I feel like I'm driving with no map. Am I totally incorrect? > > I think so, at least what you've said seemed to make sense and matches what I > remember. This stuff is very rusty to me, we've not used ColdFire parts for > a > number of years :-( Actually, lots of years. > > > > Is this the right list to be talking to? > > I should think so. > > > > Does anyone with experience (snapgear guys) have any recommendations? > > My method for debugging these problems involved hex dumps of the compiler > generated code (objdump -D is good) and a hex calculator to link everything > together. > > > The "library is younger" message comes from a date check between the flat > headers of the executable and libc. Try flthdr -p to see what values are > really present in the two executables. This check doesn't have anything to > do with relocations so if something is going awry mid way through, I'd be > suspecting memory corruption. > > > Regards, > > Pauli > -- > Dr Paul Dale > Software Grunt > > Secure Computing(r) > your trusted source for enterprise security(tm) > www.securecomputing.com <http://www.securecomputing.com/> > > > _______________________________________________ > uClinux-dev mailing list > [email protected] > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by [email protected] > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > > ************************************************************************************ > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer > viruses. > ************************************************************************************ > > > > > _______________________________________________ > uClinux-dev mailing list > [email protected] > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by [email protected] > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
