Graeme Russ <graeme.r...@gmail.com> wrote on 13/10/2009 22:06:56:
>
> On Tue, Oct 13, 2009 at 10:53 PM, Joakim Tjernlund
> <joakim.tjernl...@transmode.se> wrote:
> > Graeme Russ <graeme.r...@gmail.com> wrote on 13/10/2009 13:21:05:
> >> On Sun, Oct 11, 2009 at 11:51 PM, Joakim Tjernlund
> >> <joakim.tjernl...@transmode.se> wrote:
> >> > Graeme Russ <graeme.r...@gmail.com> wrote on 11/10/2009 12:47:19:
> >>
> >> [Massive Snip :)]
> >>
> >> >
> >> >>
> >> >> So, all that is left are .dynsym and .dynamic ...
> >> >> .dynsym
> >> >> - Contains 70 entries (16 bytes each, 1120 bytes)
> >> >> - 44 entries mimic those entries in .got which are not relocated
> >> >> - 21 entries are the remaining symbols exported from the linker
> >> >> script
> >> >> - 4 entries are labels defined in inline asm and used in C
> >> > Try adding proper asm declarations. Look at what gcc
> >> > generates for a function/variable and mimic these.
> >>
> >> Thanks - Now .dynsym contains only exports from the linker script
> > :)
> >>
> >> >
> >> >> - 1 entry is a NULL entry
> >> >>
> >> >> .dynamic
> >> >> - 88 bytes
> >> >> - Array of Elf32_Dyn
> >> >> - typedef struct {
> >> >> Elf32_Sword d_tag;
> >> >> union {
> >> >> Elf32_Word d_val;
> >> >> Elf32_Addr d_ptr;
> >> >> } d_un;
> >> >> } Elf32_Dyn;
> >> >> - 0x11 entries
> >> >> [00] 0x00000010, 0x00000000 DT_SYMBOLIC, (ignored)
> >> >> [01] 0x00000004, 0x38059994 DT_HASH, points to .hash
> >> >> [02] 0x00000005, 0x380595AB DT_STRTAB, points to .dynstr
> >> >> [03] 0x00000006, 0x3805BDCC DT_SYMTAB, points to .dynsym
> >> >> [04] 0x0000000A, 0x000003E6 DT_STRSZ, size of .dynstr
> >> >> [05] 0x0000000B, 0x00000010 DT_SYMENT, ???
> >> >> [06] 0x00000015, 0x00000000 DT_DEBUG, ???
> >> >> [07] 0x00000011, 0x3805A8F4 DT_REL, points to .rel.text
> >> >> [08] 0x00000012, 0x000014D8 DT_RELSZ, ???
> >> > How big DT_REL is
> >> >> [09] 0x00000013, 0x00000008 DT_RELENT, ???
> >> > hmm, cannot remeber :)
> >>
> >> How big an entry in DT_REL is
> >
> > Right, how could I forget :)
> >>
> >> >> [0a] 0x00000016, 0x00000000 DT_TEXTREL, ???
> >> > Oops, you got text relocations. This is generally a bad thing.
> >> > TEXTREL is commonly caused by asm code that arent truly pic so it needs
> >> > to modify the .text segment to adjust for relocation.
> >> > You should get rid of this one. Look for DT_TEXTREL in .o files to find
> >> > the culprit.
> >> >
> >>
> >> Alas I cannot - The relocations are a result of loading a register with a
> >> return address when calling show_boot_progress in the very early stages of
> >> initialisation prior to the stack becoming available. The x86 does not
> >> allow direct access to the IP so the only way to find the 'current
> >> execution address' is to 'call' to the next instruction and pop the return
> >> address off the stack
> >
> > hmm, same as ppc but that in it self should not cause a TEXREL, should it?
> > Ahh, the 'call' is absolute, not relative? I guess there is some way around
> > it
> > but it is not important ATM I guess.
> >
> > Evil idea, skip -fpic et. all and add the full reloc procedure
> > to relocate by rewriting directly in TEXT segment. Then you save space
> > but you need more relocation code. Something like dl_do_reloc from
> > uClibc. Wonder how much extra code that would be? Not too much I think.
> >
>
> With the following flags
>
> PLATFORM_RELFLAGS += -fvisibility=hidden
> PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm
> PLATFORM_LDFLAGS += -pic --emit-relocs -Bsymbolic -Bsymbolic-functions
>
> I get no .got, but a lot of R_386_PC32 and R_386_32 relocations. I think
> this might mean I need the symbol table in the binary in order to resolve
> them
Possibly, but I think you only need to add an offset to all those
relocs.
Jokce
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
