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
Ok, I've rebuilt my elf directory with the -m5200 switch while adding
the following to force elf_get_dynamic_info to be inlined in _dl_start:
ifeq ($(subdir),elf)
sysdep-CFLAGS += --param max-inline-insns=4000
endif
It goes a little fruther, and blows up in the inlined
elf_get_dynamic_info function since gcc-3.2.1 is rearranging the code
to load at the start of the inlined function the strings that can be
output if an error occurs:
00002bf6 <_dl_start>:
2bf6: 4e56 fe3c linkw %fp,#-452
2bfa: 4fef ffd8 lea %sp@(-40),%sp
2bfe: 48d7 3cfc moveml %d2-%d7/%a2-%a5,%sp@
2c02: 2a7c 0001 3514 moveal #79124,%a5
2c08: 4bfb d8fa lea %pc@(2c04 <_dl_start+0xe>,%a5:l),%a5
2c0c: 4280 clrl %d0
2c0e: 41ee fe72 lea %fp@(-398),%a0
2c12: 4298 clrl %a0@+
2c14: 5280 addql #1,%d0
2c16: 7234 moveq #52,%d1
2c18: b280 cmpl %d0,%d1
2c1a: 64f6 bccs 2c12 <_dl_start+0x1c>
2c1c: 41fa ffd8 lea %pc@(2bf6 <_dl_start>),%a0
2c20: 91ed 0010 subal %a5@(16),%a0
2c24: 2d48 fe5a movel %a0,%fp@(-422)
2c28: d1d5 addal %a5@,%a0
2c2a: 2d48 fe62 movel %a0,%fp@(-414)
2c2e: 49ee fe5a lea %fp@(-422),%a4
2c32: 206c 0008 moveal %a4@(8),%a0
2c36: 4a88 tstl %a0
2c38: 6700 00f4 beqw 2d2e <_dl_start+0x138>
2c3c: 2414 movel %a4@,%d2
2c3e: 45ec 0018 lea %a4@(24),%a2
2c42: 2210 movel %a0@,%d1
2c44: 673c beqs 2c82 <_dl_start+0x8c>
2c46: 263c 0001 2593 movel #75155,%d3
2c4c: 2635 3800 movel %a5@(00000000,%d3:l),%d3
2c50: 2a3c 0001 25a3 movel #75171,%d5
2c56: 2a35 5800 movel %a5@(00000000,%d5:l),%d5
2c5a: 2c3c 0001 25b8 movel #75192,%d6
2c60: 2c35 6800 movel %a5@(00000000,%d6:l),%d6
2c64: 283c 0001 25c7 movel #75207,%d4
2c6a: 2835 4800 movel %a5@(00000000,%d4:l),%d4
Note the loads at insns 0x2c4c, 0x2c56, 0x2c60 and 0x2c6a. At this
point, %a5 is set via the two instructions at 0x2c02 and 0x2c08 which
result in %a5 being 40015cc8 which is where the _GLOBAL_OFFSET_TABLE_
is placed.
Looking at the assembler code, I find that those instructions
correspond with the following code (at label .LM18):
.stabs "dynamic-link.h",132,0,0,.Ltext5
.Ltext5:
.stabn 68,0,38,.LM13-_dl_start
.LM13:
.LBB5:
lea (-422,%a6),%a4
.stabn 68,0,39,.LM14-_dl_start
.LM14:
.LBB6:
move.l 8(%a4),%a0
.stabn 68,0,43,.LM15-_dl_start
.LM15:
tst.l %a0
jbeq .L145
.stabn 68,0,46,.LM16-_dl_start
.LM16:
move.l (%a4),%d2
.stabn 68,0,47,.LM17-_dl_start
.LM17:
lea (24,%a4),%a2
.stabn 68,0,49,.LM18-_dl_start
.LM18:
move.l (%a0),%d1
jbeq .L277
move.l #.LC2,%d3
move.l (%a5,%d3.l),%d3
move.l #.LC3,%d5
move.l (%a5,%d5.l),%d5
move.l #.LC4,%d6
move.l (%a5,%d6.l),%d6
move.l #.LC5,%d4
move.l (%a5,%d4.l),%d4
.LC2, .LC3, ,LC4 and .LC5 are:
.section .rodata.str1.1,"aMS",@progbits,1
.LC2:
.string "bad dynamic tag"
.LC3:
.string "elf_get_dynamic_info"
.LC4:
.string "dynamic-link.h"
.LC5:
.string "! \"bad dynamic tag\""
.LC7:
.string "info[20]->d_un.d_val == 7"
.LC6:
So it looks like the compiler is trying to be helpful by hoisting the
assigments of these pointers to the start of the inlined funciton,
but unfortunatley the GOT entries are not set up correctly (yet). At
the point that instruciton at offset 0x2c94 executes, %a5 is
0x40015cc8, and %d3 is 0x12143, causing the access to be from
0x40027e0-b whihc is what matches the info->_sifields._sigfault that
firce_sig_info is called with to start killing the init process...
1) At instruction 0x2c94, what should %a5 be?
2) Should gcc try hoisting these accesses up this high?
2) Does this look right, or is something else going on here that I'm
completely overlooking?
--
Peter Barada Peter.Barada@motorola.com
Wizard 781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)