This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: questions regarding m68k/ColdFire dynamic/shared code
>|> >From the ld.so.dump, this write corresponds to:
>|>
>|> 000048ce <_dl_start_user>:
>|> 48ce: 2200 movel %d0,%d1
>|> 48d0: 2840 moveal %d0,%a4
>|> 48d2: 2a7c 0001 670c moveal #91916,%a5
>|> 48d8: 287c 0000 0028 moveal #40,%a4
>
>This is bogus, it must be something like this:
>
>00001d14 <_dl_start_user>:
> 1d14: 2840 moveal %d0,%a4
> 1d16: 4bfb 0170 0001 lea %pc@(12d34 <_GLOBAL_OFFSET_TABLE_>),%a5
> 1d1c: 101c
>
>This is required to be pc-relative addressing, ie. position independent.
ColdFire can't handle instructions that are longer than 48 bits, so I
had to re-write that code so that:
lea _GLOBAL_OFFSET_TABLE_@GOTPC(%pc), %a5
is turned into:
lea _GLOBAL_OFFSET_TABLE_@GOTPC, %a5
lea -6(%pc,%a5),%a5
Also coldfire doesn't support pre/post indexed addressing modes:
| Remember the highest stack address.
move.l %sp, ([__libc_stack_end@GOT.w, %a5])
| See if we were run as a command with the executable file
| name as an extra leading argument.
move.l ([_dl_skip_args@GOT.w, %a5]), %d0
and since I didn't understnad what the code is supposed to do, I decided to use
some of the reigsters that get overwritten (namely %d1) as temporaries. So that code
looks somethine like:
move.l %a0, %d1 | save %a0
move.l __libc_stack_end@GOT.w(%a5), %a0
move.l %sp,(%a0)
move.l _dl_skip_args@GOT.w(%a5), %a0
move.l (%a0),%d0
move.l %d1, %a0 | restore %a0
So that explins the code at _dl_start_user. This code isn't executed
yet since ld.so *looks* like its modifying itself to add the load
offset to the 32bit constant in the 'lea _GLOBAL_OFFSET_TABLE@GOTPC,
%a5' instruction.
Should ld.so modify itself?
--
Peter Barada Peter.Barada@motorola.com
Wizard 781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)