This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
RE: sorting dynamic relocation entries.
- To: 'Koundinya K' <knk at dde dot dk>, Ian Lance Taylor <ian at zembu dot com>
- Subject: RE: sorting dynamic relocation entries.
- From: Donn Terry <donnte at microsoft dot com>
- Date: Mon, 13 Mar 2000 14:11:38 -0800
- Cc: binutils at sourceware dot cygnus dot com
A little guesswork here, but this looks familiar:
a zero entry in this case indicates that the sort
is sorting extra entries beyond those that are actually
filled in. Possible causes:
- Off by one in the call to qsort().
- Off by one or more in the estimation of the size
of .rel.dyn (or not keeping the actual size used).
- Gaps in .rel.dyn (generated by putting different
types of relocations in different places within
.rel.dyn.
Since many of the dynamic linkers treat a zero entry
as "last entry", this would cause runtime relocations
to fail.
Donn
> -----Original Message-----
> From: Koundinya K [mailto:knk@dde.dk]
> Sent: Monday, March 13, 2000 11:40 AM
> To: Ian Lance Taylor
> Cc: binutils@sourceware.cygnus.com
> Subject: Re: sorting dynamic relocation entries.
>
>
> Hi Ian,
> I have not had success with this yet. Let me be more clear.
>
> Here is a simple test case which I have choosen , where I
> generate a shared library
> from 2 files. The library does contain dynamic relocations.
>
> Without sorting, this is how the library looks:
>
> Here is the section header.
>
> [10] SHT_REL 0x6f0 0x6f0 0x18
> .rel.dyn
> 4 0 0x10 0x8 ALLOC
>
>
> Here are the dynamic relocations as seen from the native dump
> tool. There are 3.
>
> 1) non verbose.
> libruf.so:
>
> **** RELOCATION INFORMATION ****
>
> .rel.dyn:
> Offset Symndx Type
>
> 0x0 0 0
> 0x40710 37 3
> 0x40720 36 3
>
> 2) in verbose
>
> libruf.so:
>
> **** RELOCATION INFORMATION ****
>
> .rel.dyn:
> Offset Symndx Type
>
> 0x0 0 _NONE
> 0x40710 foo _REL
> 0x40720 fun1 _REL
>
>
> This is from readelf:
>
> halfway:3654 [knk/work/hello] readelf -r libruf.so
>
> Relocation section '.rel.dyn' at offset 0x6f0 contains 3 entries:
> Offset Info Type
> Symbol's Value Symbol's
> Name
> 00000000 00000 R_MIPS_NONE
> 00040710 02503 R_MIPS_REL32 00000000 foo
> 00040720 02403 R_MIPS_REL32 00000000 fun1
>
>
> After reading your earlier mail, I was more clear. I have
> made chages to the
> comparison function called via qsort()
>
> This is the call to qsort() in the below code
>
> if (info->shared)
> {
> asection *reldyn;
> bfd *dynobj1;
>
> dynobj1 = elf_hash_table (info)->dynobj;
>
> reldyn = bfd_get_section_by_name (dynobj1,
>
> MIPS_ELF_REL_DYN_SECTION_NAME(dynobj1));
>
> if (reldyn !=NULL)
> {
> unsigned int dyn_reloc_cont;
> dyn_reloc_cont = reldyn->reloc_count;
>
> fprintf(stderr,"_bfd_mips_elf_final_link() Address of
> reldyn->contents=\
> t0x%lx\n",reldyn->contents);
>
> /* Perform the sort */
>
> qsort (reldyn->contents,
> (size_t) dyn_reloc_cont, sizeof(Elf32_External_Rel),
> sort_dynamic_relocations);
> }
> } /********************/
>
> /* Sort the dynamic relocations based on the symbol index.
> This is called
> via qsort() */
>
> /* Note: Here for testing I am trying to print and observe
> the values through
> fprintf's or debugger */
>
> static int
> sort_dynamic_relocations (arg1, arg2)
> const void *arg1;
> const void *arg2;
> {
>
> const Elf32_External_Rel *rel1 = (const Elf32_External_Rel *) arg1;
> const Elf32_External_Rel *rel2 = (const Elf32_External_Rel *) arg2;
>
> fprintf(stderr,"sort_dynamic_relocations()
> rel1(offset)=\t0x%lx\n",rel1->r_offset);
> fprintf(stderr,"sort_dynamic_relocations()
> rel1(info)=\t0x%lx\n",rel1->r_info);
>
> fprintf(stderr,"sort_dynamic_relocations()
> rel2(offset)=\t0x%lx\n",rel2->r_offset);
> fprintf(stderr,"sort_dynamic_relocations()
> rel2(info)=\t0x%lx\n",rel2->r_info);
>
>
>
>
> /* Do the comparison and return appropriately . Not
> using this yet !!*/
> .....................................
> .......................................
> .........................................
> }
>
> Well, the offset and r_info values for the relocations are
> printed as 0x0.
>
> Here are are the values that I am trying to watch in the
> debugger and this is what
> they show. rel1 and rel2 point to the exact address of each
> of the relocations. But
> why there are no values for r_offset and r_info is sounding
> quite mysterious.
>
>
> arg1 = 0x47f3a8
> arg1 = 0x47f3b0
>
> rel1 = 0x47f3a8
> rel2 = 0x47f3b0
>
> *rel1 = {r_offset = "",r_info=""}
> *rel2 = {r_offset = "",r_info=""}
>
> ______________________________________________________________
> _______________
>
> arg1 = 0x47f3b0
> arg1 = 0x47f3b8
>
> rel1 = 0x47f3b0
> rel2 = 0x47f3b8
>
> *rel1 = {r_offset = "",r_info=""}
> *rel2 = {r_offset = "",r_info=""}
>
> ______________________________________________________________
> _______________
>
> arg1 = 0x47f3a8
> arg1 = 0x47f3b0
>
> rel1 = 0x47f3a8
> rel2 = 0x47f3b0
>
> *rel1 = {r_offset = "",r_info=""}
> *rel2 = {r_offset = "",r_info=""}
>
>
>
> But using the debugger when I dump the contents of memory
> address hat point to the
> r_offset and r_info values of the relocations, I see the
> right values. For instance
> look at the r_offset and r_info values for one of the relocs.
>
> dump 0x47f3b0
> 0x0047f3b0: 0x00040710
> dump 0x47f3b4
> 0x0047f3b4: 0x00002503
>
> Like wise I can see the exact values for the other relocs.
>
> But again why is it that I am not able to access these ??.
>
> What could be wrong ??. Please suggest.
>
> Thanks a lot.,
>
> koundinya
>