[U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?

[U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?

[wang baohua]

Dear all,
 I study the U-boot.bin file using the objdump command, I don't know how the
CPU can find the right string address when puts() string.
 For example, In my binary file, the string "Call backtrace: " in func
"print_backtrace()" address is :0x0002b280, the func address is
 0xfff03564, How the CPU can find the 0x0002b280 when call  puts ("Call
backtrace: "); ?  I find the SMC serial driver
 "serial_putc()" but cannot know how to find the char address in binary
file.

Below is the objdump result, can anyone explain to me ? thanks!

(PowerPC platform)
void print_backtrace(unsigned long *sp)
{
int cnt = 0;
unsigned long i;

puts ("Call backtrace: ");
while (sp) {
if ((uint)sp > END_OF_MEM)
break;

i = sp[1];
if (cnt++ % 7 == 0)
putc ('\n');
printf("%08lX ", i);
if (cnt > 32) break;
sp = (unsigned long *)*sp;
}
putc ('\n');
}

void show_regs(struct pt_regs * regs)
{
int i;

printf("NIP: %08lX XER: %08lX LR: %08lX REGS: %p TRAP: %04lx DAR: %08lX\n",
regs->nip, regs->xer, regs->link, regs, regs->trap, regs->dar);
printf("MSR: %08lx EE: %01x PR: %01x FP: %01x ME: %01x IR/DR: %01x%01x\n",
regs->msr, regs->msr&MSR_EE ? 1 : 0, regs->msr&MSR_PR ? 1 : 0,
regs->msr & MSR_FP ? 1 : 0,regs->msr&MSR_ME ? 1 : 0,
regs->msr&MSR_IR ? 1 : 0,
regs->msr&MSR_DR ? 1 : 0);

putc ('\n');
for (i = 0; i < 32; i++) {
if ((i % 8) == 0) {
printf("GPR%02d: ", i);
}

printf("%08lX ", regs->gpr[i]);
if ((i % 8) == 7) {
putc ('\n');
}
}
}

void puts (const char *s)
{
DECLARE_GLOBAL_DATA_PTR;

#ifdef CONFIG_SILENT_CONSOLE
if (gd->flags & GD_FLG_SILENT)
return;
#endif

if (gd->flags & GD_FLG_DEVINIT) {
/* Send to the standard output */
fputs (stdout, s);
} else {
/* Send directly to the handler */
serial_puts (s);
}
}

void serial_putc(const char c)
{
volatile cbd_t *tbdf;
volatile char *buf;
volatile smc_uart_t *up;
volatile immap_t *im = (immap_t *)CFG_IMMR;

if (c == '\n')
serial_putc ('\r');

up = (smc_uart_t *)&(im->im_dprambase[PROFF_SMC]);

tbdf = (cbd_t *)&im->im_dprambase[up->smc_tbase];

/* Wait for last character to go.
*/
buf = (char *)tbdf->cbd_bufaddr;
while (tbdf->cbd_sc & BD_SC_READY)
;

*buf = c;
tbdf->cbd_datlen = 1;
tbdf->cbd_sc |= BD_SC_READY;
}

------------------------------------------------------------------------------------
hex code in u-boot.bin
string:
0002b280h: 43 61 6C 6C 20 62 61 63 6B 74 72 61 63 65 3A 20 ; Call backtrace:

0002b290h: 00 00 00 00 25 30 38 6C 58 20 00 00 4E 49 50 3A ; ....%08lX
..NIP:
0002b2a0h: 20 25 30 38 6C 58 20 58 45 52 3A 20 25 30 38 6C ; %08lX XER: %08l
0002b2b0h: 58 20 4C 52 3A 20 25 30 38 6C 58 20 52 45 47 53 ; X LR: %08lX
REGS
0002b2c0h: 3A 20 25 70 20 54 52 41 50 3A 20 25 30 34 6C 78 ; : %p TRAP:
%04lx
0002b2d0h: 20 44 41 52 3A 20 25 30 38 6C 58 0A 00 00 00 00 ; DAR: %08lX.....
0002b2e0h: 4D 53 52 3A 20 25 30 38 6C 78 20 45 45 3A 20 25 ; MSR: %08lx EE:
%
0002b2f0h: 30 31 78 20 50 52 3A 20 25 30 31 78 20 46 50 3A ; 01x PR: %01x
FP:
0002b300h: 20 25 30 31 78 20 4D 45 3A 20 25 30 31 78 20 49 ; %01x ME: %01x I
0002b310h: 52 2F 44 52 3A 20 25 30 31 78 25 30 31 78 0A 00 ; R/DR:
%01x%01x..
0002b320h: 47 50 52 25 30 32 64 3A ; GPR%02d:


hex code in u-boot.bin
func:
print_backtrace()
00003584h: 94 21 FF D8 7C 08 02 A6 42 9F 00 05 BF 61 00 14 ;
?&#63733;?|..?B?.?a..
00003594h: 7F C8 02 A6 90 01 00 2C 80 1E FF F0 7C 7C 1B 78 ;
\x7f???..,&#8364;.&#63733;?||.x
000035a4h: 3B E0 00 00 7F C0 F2 14 80 7E 80 00 48 01 1B AD ;
;?.\x7f??.&#8364;~&#8364;.H..?
000035b4h: 2C 1C 00 00 41 82 00 70 3C 00 02 00 7C 1C 00 40 ; ,...A?p<...|..@
000035c4h: 3D 20 92 49 61 29 24 93 7F EB FE 70 38 60 00 0A ; = 'Ia)$???p8`..
000035d4h: 41 81 00 54 7C 1F 48 96 83 7C 00 04 7C 00 FA 14 ; A?T|.H??|..|.?
000035e4h: 7C 00 16 70 7C 0B 00 50 1C 00 00 07 7C 00 F8 50 ;
|..p|..P....|.?P
000035f4h: 2C 00 00 00 3B FF 00 01 40 A2 00 08 48 01 1B 21 ;
,...;&#63733;..@?.H..!
00003604h: 80 7E 80 04 7F 64 DB 78 4C C6 31 82 48 01 1B 89 ;
&#8364;~&#8364;.\x7fd?xL??H..?
00003614h: 2C 1F 00 20 41 81 00 10 83 9C 00 00 2C 1C 00 00 ; ,.. A?.??..,...
00003624h: 40 82 FF 98 38 60 00 0A 48 01 1A F5 BB 61 00 14 ; @??`..H..??a..
00003634h: 80 01 00 2C 38 21 00 28 7C 08 03 A6 4E 80 00 20 ;
&#8364;..,8!.(|..?N&#8364;.
00003644h: 00 03 89 F0 ; ..??

show_regs()
00003648h: 94 21 FF E8 7C 08 02 A6 42 9F 00 05 BF 81 00 08 ;
?&#63733;?|..?B?.??..
00003658h: 7F C8 02 A6 90 01 00 1C 80 1E FF F0 7C 7F 1B 78 ;
\x7f???...&#8364;.&#63733;?|\x7f.x
00003668h: 80 9F 00 80 7F E7 FB 78 7F C0 F2 14 80 BF 00 94 ;
&#8364;?&#8364;\x7f??x\x7f??.&#8364;??
00003678h: 80 7E 80 08 3B 80 00 00 80 DF 00 90 81 1F 00 A0 ;
&#8364;~&#8364;.;&#8364;..&#8364;???..?
00003688h: 81 3F 00 A4 4C C6 31 82 48 01 1B 09 80 9F 00 84 ;
?.?L??H...&#8364;??
00003698h: 80 7E 80 0C 54 85 8F FE 54 86 97 FE 54 87 9F FE ;
&#8364;~&#8364;.T??&#59417;??&#59417;???
000036a8h: 54 88 A7 FE 54 89 DF FE 54 8A E7 FE 4C C6 31 82 ;
T??&#59417;??&#59417;???L??
000036b8h: 48 01 1A E1 38 60 00 0A 48 01 1A 61 73 80 00 07 ;
H..?`..H..as&#8364;..
000036c8h: 7F 84 E3 78 40 A2 00 10 80 7E 80 10 4C C6 31 82 ; \x7f??x@
?.&#8364;~&#8364;.L??
000036d8h: 48 01 1A C1 57 80 10 3A 80 7E 80 04 7C 9F 00 2E ;
H..?W&#8364;.:&#8364;~&#8364;.|?.
000036e8h: 4C C6 31 82 48 01 1A AD 38 60 00 0A 7F 80 1E 70 ;
L??H..?`..\x7f&#8364;.p
000036f8h: 7C 00 01 94 54 00 18 38 7C 00 E0 50 2C 00 00 07 ;
|.."T..8|.?P,...
00003708h: 3B 9C 00 01 40 A2 00 08 48 01 1A 11 2C 1C 00 1F ; ;?.@?.H...,...
00003718h: 40 81 FF AC 80 01 00 1C BB 81 00 08 38 21 00 18 ; @???...??..8!..
00003728h: 7C 08 03 A6 4E 80 00 20 00 03 89 04 ; |..?N&#8364;. ..?

puts()
0001515ch: 94 21 FF E8 7C 08 02 A6 90 01 00 1C 7C 64 1B 78 ;
?&#63733;?|..??...|d.x
0001516ch: 80 1D 00 04 70 09 00 02 41 82 00 10 38 60 00 01 ;
&#8364;...p...A?.8`..
0001517ch: 4B FF FE 4D 48 00 00 08 48 00 FE 89 80 01 00 1C ;
K&#63733;?MH...H.&#59469;&#8364;...
0001518ch: 38 21 00 18 7C 08 03 A6 4E 80 00 20 ; 8!..|..?N&#8364;.

serial_putc()
00024f9ch: 2C 03 00 0A 94 21 FF E8 7C 08 02 A6 93 E1 00 10 ;
,...?&#63733;?|..?"?.
00024fach: 90 01 00 1C 7C 7F 1B 78 40 A2 00 0C 38 60 00 0D ; ?..|\x7f.x@?.8`..
00024fbch: 4B FF FF E1 3D 20 F0 00 A1 29 00 02 3D 29 F0 00 ;
K&#63733;&#63733;? ??..=)?
00024fcch: 81 69 00 04 A8 09 00 00 2C 00 00 00 41 80 FF F8 ;
?i..?..,...A&#8364;&#63733;?
00024fdch: 38 00 00 01 9B EB 00 00 B0 09 00 02 A0 09 00 00 ; 8...??..?..?..
00024fech: 83 E1 00 10 64 00 FF FF 60 00 80 00 B0 09 00 00 ;
??..d.&#63733;&#63733;`.&#8364;.?..
00024ffch: 80 01 00 1C 38 21 00 18 7C 08 03 A6 4E 80 00 20 ;
&#8364;...8!..|..?N&#8364;.

-------------------------------------------------------------------------------------
assemble code
fff03564 <print_backtrace>: ---> length: C0,  u-boot.bin  address
0x00003584,offset address: 0xFFEFFFE0
fff03564: 94 21 ff d8 stwu r1,-40(r1)
fff03568: 7c 08 02 a6 mflr r0
fff0356c: 42 9f 00 05 bcl- 20,4*cr7+so,fff03570 <print_backtrace+0xc>
fff03570: bf 61 00 14 stmw r27,20(r1)
fff03574: 7f c8 02 a6 mflr r30
fff03578: 90 01 00 2c stw r0,44(r1)
fff0357c: 80 1e ff f0 lwz r0,-16(r30)
fff03580: 7c 7c 1b 78 mr r28,r3
fff03584: 3b e0 00 00 li r31,0
fff03588: 7f c0 f2 14 add r30,r0,r30
fff0358c: 80 7e 80 00 lwz r3,-32768(r30)
fff03590: 48 01 1b ad bl fff1513c <puts>
fff03594: 2c 1c 00 00 cmpwi r28,0
fff03598: 41 82 00 70 beq- fff03608 <print_backtrace+0xa4>
fff0359c: 3c 00 02 00 lis r0,512
fff035a0: 7c 1c 00 40 cmplw r28,r0
fff035a4: 3d 20 92 49 lis r9,-28087
fff035a8: 61 29 24 93 ori r9,r9,9363
fff035ac: 7f eb fe 70 srawi r11,r31,31
fff035b0: 38 60 00 0a li r3,10
fff035b4: 41 81 00 54 bgt- fff03608 <print_backtrace+0xa4>
fff035b8: 7c 1f 48 96 mulhw r0,r31,r9
fff035bc: 83 7c 00 04 lwz r27,4(r28)
fff035c0: 7c 00 fa 14 add r0,r0,r31
fff035c4: 7c 00 16 70 srawi r0,r0,2
fff035c8: 7c 0b 00 50 subf r0,r11,r0
fff035cc: 1c 00 00 07 mulli r0,r0,7
fff035d0: 7c 00 f8 50 subf r0,r0,r31
fff035d4: 2c 00 00 00 cmpwi r0,0
fff035d8: 3b ff 00 01 addi r31,r31,1
fff035dc: 40 a2 00 08 bne+ fff035e4 <print_backtrace+0x80>
fff035e0: 48 01 1b 21 bl fff15100 <putc>
fff035e4: 80 7e 80 04 lwz r3,-32764(r30)
fff035e8: 7f 64 db 78 mr r4,r27
fff035ec: 4c c6 31 82 crclr 4*cr1+eq
fff035f0: 48 01 1b 89 bl fff15178 <printf>
fff035f4: 2c 1f 00 20 cmpwi r31,32
fff035f8: 41 81 00 10 bgt- fff03608 <print_backtrace+0xa4>
fff035fc: 83 9c 00 00 lwz r28,0(r28)
fff03600: 2c 1c 00 00 cmpwi r28,0
fff03604: 40 82 ff 98 bne+ fff0359c <print_backtrace+0x38>
fff03608: 38 60 00 0a li r3,10
fff0360c: 48 01 1a f5 bl fff15100 <putc>
fff03610: bb 61 00 14 lmw r27,20(r1)
fff03614: 80 01 00 2c lwz r0,44(r1)
fff03618: 38 21 00 28 addi r1,r1,40
fff0361c: 7c 08 03 a6 mtlr r0
fff03620: 4e 80 00 20 blr
fff03624: 00 03 89 f0 .long 0x389f0

fff03628 <show_regs>: --->length 0xE8,  u-boot.bin  address
0x00003648,offset address: 0xFFEFFFE0
fff03628: 94 21 ff e8 stwu r1,-24(r1)
fff0362c: 7c 08 02 a6 mflr r0
fff03630: 42 9f 00 05 bcl- 20,4*cr7+so,fff03634 <show_regs+0xc>
fff03634: bf 81 00 08 stmw r28,8(r1)
fff03638: 7f c8 02 a6 mflr r30
fff0363c: 90 01 00 1c stw r0,28(r1)
fff03640: 80 1e ff f0 lwz r0,-16(r30)
fff03644: 7c 7f 1b 78 mr r31,r3
fff03648: 80 9f 00 80 lwz r4,128(r31)
fff0364c: 7f e7 fb 78 mr r7,r31
fff03650: 7f c0 f2 14 add r30,r0,r30
fff03654: 80 bf 00 94 lwz r5,148(r31)
fff03658: 80 7e 80 08 lwz r3,-32760(r30)
fff0365c: 3b 80 00 00 li r28,0
fff03660: 80 df 00 90 lwz r6,144(r31)
fff03664: 81 1f 00 a0 lwz r8,160(r31)
fff03668: 81 3f 00 a4 lwz r9,164(r31)
fff0366c: 4c c6 31 82 crclr 4*cr1+eq
fff03670: 48 01 1b 09 bl fff15178 <printf>
fff03674: 80 9f 00 84 lwz r4,132(r31)
fff03678: 80 7e 80 0c lwz r3,-32756(r30)
fff0367c: 54 85 8f fe rlwinm r5,r4,17,31,31
fff03680: 54 86 97 fe rlwinm r6,r4,18,31,31
fff03684: 54 87 9f fe rlwinm r7,r4,19,31,31
fff03688: 54 88 a7 fe rlwinm r8,r4,20,31,31
fff0368c: 54 89 df fe rlwinm r9,r4,27,31,31
fff03690: 54 8a e7 fe rlwinm r10,r4,28,31,31
fff03694: 4c c6 31 82 crclr 4*cr1+eq
fff03698: 48 01 1a e1 bl fff15178 <printf>
fff0369c: 38 60 00 0a li r3,10
fff036a0: 48 01 1a 61 bl fff15100 <putc>
fff036a4: 73 80 00 07 andi. r0,r28,7
fff036a8: 7f 84 e3 78 mr r4,r28
fff036ac: 40 a2 00 10 bne+ fff036bc <show_regs+0x94>
fff036b0: 80 7e 80 10 lwz r3,-32752(r30)
fff036b4: 4c c6 31 82 crclr 4*cr1+eq
fff036b8: 48 01 1a c1 bl fff15178 <printf>
fff036bc: 57 80 10 3a rlwinm r0,r28,2,0,29
fff036c0: 80 7e 80 04 lwz r3,-32764(r30)
fff036c4: 7c 9f 00 2e lwzx r4,r31,r0
fff036c8: 4c c6 31 82 crclr 4*cr1+eq
fff036cc: 48 01 1a ad bl fff15178 <printf>
fff036d0: 38 60 00 0a li r3,10
fff036d4: 7f 80 1e 70 srawi r0,r28,3
fff036d8: 7c 00 01 94 addze r0,r0
fff036dc: 54 00 18 38 rlwinm r0,r0,3,0,28
fff036e0: 7c 00 e0 50 subf r0,r0,r28
fff036e4: 2c 00 00 07 cmpwi r0,7
fff036e8: 3b 9c 00 01 addi r28,r28,1
fff036ec: 40 a2 00 08 bne+ fff036f4 <show_regs+0xcc>
fff036f0: 48 01 1a 11 bl fff15100 <putc>
fff036f4: 2c 1c 00 1f cmpwi r28,31
fff036f8: 40 81 ff ac ble+ fff036a4 <show_regs+0x7c>
fff036fc: 80 01 00 1c lwz r0,28(r1)
fff03700: bb 81 00 08 lmw r28,8(r1)
fff03704: 38 21 00 18 addi r1,r1,24
fff03708: 7c 08 03 a6 mtlr r0
fff0370c: 4e 80 00 20 blr
fff03710: 00 03 89 04 .long 0x38904


fff1513c <puts>: ---> Length 0x38,  u-boot.bin  0x0001515c,  Offset address:
0xFFEFFFE0
fff1513c: 94 21 ff e8 stwu r1,-24(r1)
fff15140: 7c 08 02 a6 mflr r0
fff15144: 90 01 00 1c stw r0,28(r1)
fff15148: 7c 64 1b 78 mr r4,r3
fff1514c: 80 1d 00 04 lwz r0,4(r29)
fff15150: 70 09 00 02 andi. r9,r0,2
fff15154: 41 82 00 10 beq- fff15164 <puts+0x28>
fff15158: 38 60 00 01 li r3,1
fff1515c: 4b ff fe 4d bl fff14fa8 <fputs>
fff15160: 48 00 00 08 b fff15168 <puts+0x2c>
fff15164: 48 00 fe 89 bl fff24fec <serial_puts>
fff15168: 80 01 00 1c lwz r0,28(r1)
fff1516c: 38 21 00 18 addi r1,r1,24
fff15170: 7c 08 03 a6 mtlr r0
fff15174: 4e 80 00 20 blr


fff24f7c <serial_putc>: Length 0x6C
fff24f7c: 2c 03 00 0a cmpwi r3,10
fff24f80: 94 21 ff e8 stwu r1,-24(r1)
fff24f84: 7c 08 02 a6 mflr r0
fff24f88: 93 e1 00 10 stw r31,16(r1)
fff24f8c: 90 01 00 1c stw r0,28(r1)
fff24f90: 7c 7f 1b 78 mr r31,r3
fff24f94: 40 a2 00 0c bne+ fff24fa0 <serial_putc+0x24>
fff24f98: 38 60 00 0d li r3,13
fff24f9c: 4b ff ff e1 bl fff24f7c <serial_putc>
fff24fa0: 3d 20 f0 00 lis r9,-4096
fff24fa4: a1 29 00 02 lhz r9,2(r9)
fff24fa8: 3d 29 f0 00 addis r9,r9,-4096
fff24fac: 81 69 00 04 lwz r11,4(r9)
fff24fb0: a8 09 00 00 lha r0,0(r9)
fff24fb4: 2c 00 00 00 cmpwi r0,0
fff24fb8: 41 80 ff f8 blt+ fff24fb0 <serial_putc+0x34>
fff24fbc: 38 00 00 01 li r0,1
fff24fc0: 9b eb 00 00 stb r31,0(r11)
fff24fc4: b0 09 00 02 sth r0,2(r9)
fff24fc8: a0 09 00 00 lhz r0,0(r9)
fff24fcc: 83 e1 00 10 lwz r31,16(r1)
fff24fd0: 64 00 ff ff oris r0,r0,65535
fff24fd4: 60 00 80 00 ori r0,r0,32768
fff24fd8: b0 09 00 00 sth r0,0(r9)
fff24fdc: 80 01 00 1c lwz r0,28(r1)
fff24fe0: 38 21 00 18 addi r1,r1,24
fff24fe4: 7c 08 03 a6 mtlr r0
fff24fe8: 4e 80 00 20 blr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080604/d40daa5b/attachment.htm 

[U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?

[Jerry Van Baren]

wang baohua wrote:
> Dear all,
>  I study the U-boot.bin file using the objdump command, I don't know how 
> the CPU can find the right string address when puts() string.
>  For example, In my binary file, the string "Call backtrace: " in func 
> "print_backtrace()" address is :0x0002b280, the func address is
>  0xfff03564, How the CPU can find the 0x0002b280 when call  puts ("Call 
> backtrace: "); ?  I find the SMC serial driver
>  "serial_putc()" but cannot know how to find the char address in binary 
> file.
>  
> Below is the objdump result, can anyone explain to me ? thanks!

Please don't post HTML, use plain text.

I don't understand your question, why are you asking it?  Are you trying 
to figure out a problem or are you just trying to understand the linking 
processes?

Using objdump on u-boot.bin is not valid.  U-boot.bin is a binary file, 
objdump works on ELF (linker formatted) files.

<http://en.wikipedia.org/wiki/Executable_and_Linkable_Format>

When you link the ELF files, the linker fixes up all the addresses so 
the linker sets the proper address in the instruction that the CPU 
ultimately executes.  The u-boot.bin file is a raw binary dump of the 
result.

Was that your question???

Best regards,
gvb

[U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?

[Kenneth Johansson]

On Wed, 2008-06-04 at 12:04 +0800, wang baohua wrote:
> Dear all,
>  I study the U-boot.bin file using the objdump command, I don't know
> how the CPU can find the right string address when puts() string.
>  For example, In my binary file, the string "Call backtrace: " in func
> "print_backtrace()" address is :0x0002b280, the func address is 
>  0xfff03564, How the CPU can find the 0x0002b280 when call  puts
> ("Call backtrace: "); ?  I find the SMC serial driver
>  "serial_putc()" but cannot know how to find the char address in
> binary file.

it's not exactly clear what you ask but lets start from the beginning. 

r3 is the register used by a function call that takes one argument. 
so puts() will print the string that is in this register when it is
called. 

for the caller to get the correct address into r3 is a bit more work.
u-boot is for powerpc compiled to be relocatable so the actual address
of the string will be put into one entry in the  GOT table (.got2
section). The compiler will then generate code that reads out the
address from this table and put it into r3. 

In the code below you can se that at address fff0358c r3 is set to what
is in entry 0 in the .got table. hint r30 points in the middle of the
table and quite possible outside any memory you have this is since the
register offset is singed value and we want to maximize the numbers of
entries.


> assemble code
> fff03564 <print_backtrace>: ---> length: C0,  u-boot.bin  address
> 0x00003584,offset address: 0xFFEFFFE0
> fff03564: 94 21 ff d8 stwu r1,-40(r1)
> fff03568: 7c 08 02 a6 mflr r0
> fff0356c: 42 9f 00 05 bcl- 20,4*cr7+so,fff03570 <print_backtrace+0xc>
> fff03570: bf 61 00 14 stmw r27,20(r1)
> fff03574: 7f c8 02 a6 mflr r30
> fff03578: 90 01 00 2c stw r0,44(r1)
> fff0357c: 80 1e ff f0 lwz r0,-16(r30)
> fff03580: 7c 7c 1b 78 mr r28,r3
> fff03584: 3b e0 00 00 li r31,0
> fff03588: 7f c0 f2 14 add r30,r0,r30
> fff0358c: 80 7e 80 00 lwz r3,-32768(r30)
> fff03590: 48 01 1b ad bl fff1513c <puts>

[U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?

[wang baohua]

Sorry for my poor English. I want to clearly understand the linking
processes,especially detail string loading process.
In fact, I use objcopy to convert the u-boot.bin to u-boot.elf, then using
objdump to process elf.
(In my real enviroment, I only had the MIPS arch binary format, need to
convert it first. )
"u-boot.bin file is a raw binary dump of the result". Can you detail tell me
the how to find the right string address when call puts("") in a func ? Now
I know the string in the .got section, but how to calc the loading address ?
there need some address convert from the binary file,
you see the string "Call backtrace:" address is 0x0002b280, func
print_backtrace() address is 0x00003584(in objdump is 0xfff03564), module
traps.o .got2  address  is 0xfff34024.
What's the relationship among them ?

I update the dump info, please see it.

--------------------------------------------------------------------------------------------------------------
u-boot.map

.reloc          0xfff34000     0x1578
 *(.got)
                0xfff34000                _GOT2_TABLE_ = .
 *(.got2)
 .got2          0xfff34000       0x24 cpu/mpc8260/start.o
 .got2          0xfff34024       0x4c cpu/mpc8260/libmpc8260.a(traps.o)
 ------------------------------------------------------------------------------------------------------------------
fff03564 <print_backtrace>
fff03564:    94 21 ff d8       stwu    r1,-40(r1)
fff03568:    7c 08 02 a6     mflr    r0
fff0356c:    42 9f 00 05      bcl-    20,4*cr7+so,fff03570
<print_backtrace+0xc>
fff03570:    bf 61 00 14      stmw    r27,20(r1)
fff03574:    7f c8 02 a6      mflr    r30
fff03578:    90 01 00 2c     stw     r0,44(r1)
fff0357c:    80 1e ff f0        lwz     r0,-16(r30)
fff03580:    7c 7c 1b 78     mr      r28,r3
fff03584:    3b e0 00 00     li      r31,0
fff03588:    7f c0 f2 14       add     r30,r0,r30
fff0358c:    80 7e 80 00     lwz     r3,-32768(r30)
fff03590:    48 01 1b ad     bl      fff1513c <puts>
fff03594:    2c 1c 00 00     cmpwi   r28,0
fff03598:    41 82 00 70     beq-    fff03608
<print_backtrace+0xa4>
fff0359c:    3c 00 02 00     lis     r0,512
fff035a0:    7c 1c 00 40     cmplw   r28,r0
fff035a4:    3d 20 92 49     lis     r9,-28087
fff035a8:    61 29 24 93     ori     r9,r9,9363
fff035ac:    7f eb fe 70       srawi   r11,r31,31
fff035b0:    38 60 00 0a     li      r3,10
fff035b4:    41 81 00 54     bgt-    fff03608
<print_backtrace+0xa4>
fff035b8:    7c 1f 48 96      mulhw   r0,r31,r9
fff035bc:    83 7c 00 04     lwz     r27,4(r28)
fff035c0:    7c 00 fa 14      add     r0,r0,r31
fff035c4:    7c 00 16 70     srawi   r0,r0,2
fff035c8:    7c 0b 00 50     subf    r0,r11,r0
fff035cc:    1c 00 00 07     mulli   r0,r0,7
fff035d0:    7c 00 f8 50      subf    r0,r0,r31
fff035d4:    2c 00 00 00     cmpwi   r0,0
fff035d8:    3b ff 00 01       addi    r31,r31,1
fff035dc:    40 a2 00 08     bne+    fff035e4
<print_backtrace+0x80>
fff035e0:    48 01 1b 21     bl      fff15100 <putc>
fff035e4:    80 7e 80 04     lwz     r3,-32764(r30)
fff035e8:    7f 64 db 78      mr      r4,r27
fff035ec:    4c c6 31 82     crclr   4*cr1+eq
fff035f0:    48 01 1b 89      bl      fff15178 <printf>
fff035f4:    2c 1f 00 20       cmpwi   r31,32
fff035f8:    41 81 00 10      bgt-    fff03608
<print_backtrace+0xa4>
fff035fc:    83 9c 00 00      lwz     r28,0(r28)
fff03600:    2c 1c 00 00     cmpwi   r28,0
fff03604:    40 82 ff 98       bne+    fff0359c
<print_backtrace+0x38>
fff03608:    38 60 00 0a     li      r3,10
fff0360c:    48 01 1a f5      bl      fff15100 <putc>
fff03610:    bb 61 00 14     lmw     r27,20(r1)
fff03614:    80 01 00 2c     lwz     r0,44(r1)
fff03618:    38 21 00 28     addi    r1,r1,40
fff0361c:    7c 08 03 a6     mtlr    r0
fff03620:    4e 80 00 20     blr
fff03624:    00 03 89 f0     .long 0x389f0
-------------------------------------------------------------------------------------------------------------------
u-boot.bin
0002b280h: 43 61 6C 6C 20 62 61 63 6B 74 72 61 63 65 3A 20 ; Call backtrace:


print_backtrace()
00003584h: 94 21 FF D8 7C 08 02 A6 42 9F 00 05 BF 61 00 14 ; ???..??.?..
00003594h: 7F C8 02 A6 90 01 00 2C 80 1E FF F0 7C 7C 1B 78 ; \x7f??..,?.??|.x
000035a4h: 3B E0 00 00 7F C0 F2 14 80 7E 80 00 48 01 1B AD ; ;?.\x7f?.?~?.H..?
000035b4h: 2C 1C 00 00 41 82 00 70 3C 00 02 00 7C 1C 00 40 ; ,...A?p<...|..@
000035c4h: 3D 20 92 49 61 29 24 93 7F EB FE 70 38 60 00 0A ; = ?a)$??p8`..
000035d4h: 41 81 00 54 7C 1F 48 96 83 7C 00 04 7C 00 FA 14 ; A?T|.H?|..|.?
000035e4h: 7C 00 16 70 7C 0B 00 50 1C 00 00 07 7C 00 F8 50 ; |..p|..P....|.?
000035f4h: 2C 00 00 00 3B FF 00 01 40 A2 00 08 48 01 1B 21 ; ,...;?..@?.H..!
00003604h: 80 7E 80 04 7F 64 DB 78 4C C6 31 82 48 01 1B 89 ; ?~?.\x7fd?L??..?
00003614h: 2C 1F 00 20 41 81 00 10 83 9C 00 00 2C 1C 00 00 ; ,.. A?.?..,...
00003624h: 40 82 FF 98 38 60 00 0A 48 01 1A F5 BB 61 00 14 ; @??`..H..?a..
00003634h: 80 01 00 2C 38 21 00 28 7C 08 03 A6 4E 80 00 20 ; ?..,8!.(|..??.
00003644h: 00 03 89 F0                                     ; ..?

---------------------------------------------------------------------------------------------------------------------
cpu\mpc8260\traps.c
void  print_backtrace(unsigned long *sp)
{
    int cnt = 0;
    unsigned long i;

    puts ("Call backtrace: ");
    while (sp) {
        if ((uint)sp > END_OF_MEM)
            break;

        i = sp[1];
        if (cnt++ % 7 == 0)
            putc ('\n');
        printf("%08lX ", i);
        if (cnt > 32) break;
        sp = (unsigned long *)*sp;
    }
    putc ('\n');
}






On Wed, Jun 4, 2008 at 8:49 PM, Jerry Van Baren <gerald.vanbaren@ge.com>
wrote:
> wang baohua wrote:
>>
>> Dear all,
>>  I study the U-boot.bin file using the objdump command, I don't know how
>> the CPU can find the right string address when puts() string.
>>  For example, In my binary file, the string "Call backtrace: " in func
>> "print_backtrace()" address is :0x0002b280, the func address is
>>  0xfff03564, How the CPU can find the 0x0002b280 when call  puts ("Call
>> backtrace: "); ?  I find the SMC serial driver
>>  "serial_putc()" but cannot know how to find the char address in binary
>> file.
>>  Below is the objdump result, can anyone explain to me ? thanks!
>
> Please don't post HTML, use plain text.
>
> I don't understand your question, why are you asking it?  Are you trying
to
> figure out a problem or are you just trying to understand the linking
> processes?
>
> Using objdump on u-boot.bin is not valid.  U-boot.bin is a binary file,
> objdump works on ELF (linker formatted) files.
>
> <http://en.wikipedia.org/wiki/Executable_and_Linkable_Format>
>
> When you link the ELF files, the linker fixes up all the addresses so the
> linker sets the proper address in the instruction that the CPU ultimately
> executes.  The u-boot.bin file is a raw binary dump of the result.
>
> Was that your question???
>
> Best regards,
> gvb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080605/d02edd10/attachment.htm 

[U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?

[Kenneth Johansson]

On Thu, 2008-06-05 at 09:50 +0800, wang baohua wrote:
> Dear Johansson,
>  Thanks for your reply. Your reply is very clear, that's just my
> question. In fact, I am study a
> MIPS binary file, but I cannot find any resource, so I turn to PowerPC
> platform and try to get
> clear understand about the string loading process.

I'm not sure how similar MIPS is to ppc ABI.  

> I want to ask according to your reply:
> 1. fff0358c: 80 7e 80 00     lwz r3,-32768(r30)
>    Is the -32768 stand for  " entry 0 in the .got table" ?  Why such a
> translate in objdump?

It's not objectdump that do this it's the compiler that generate the
code like this. r30 is a pointer to the GOT table but the pointer is
located so that it's possible to use the full range of the 16 bit signed
offset. that is if the GOT table only have one entry the r30 value would
be pointing outside of the table but since it's accessed with a singed
offset it will still work. 

> 2. I found the .got2 section in the U-boot.map, can you tell me how to
> calc the right string address (traps.o) ?
>    .reloc          0xfff34000     0x1578
>    *(.got)
>                      0xfff34000                _GOT2_TABLE_ = .
>   *(.got2)
>  .got2          0xfff34000       0x24 cpu/mpc8260/start.o
>  .got2          0xfff34024       0x4c cpu/mpc8260/libmpc8260.a(traps.o)

?? I thought this was obvious. to get the entry from the code take the
offset value used in the load and subtract -32768 to get the offset into
the .got2 section. at that address will be a 32 bit address that is the
address of the string. 

> thanks!

[U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?

[Jerry Van Baren]

Kenneth Johansson wrote:
> On Thu, 2008-06-05 at 09:50 +0800, wang baohua wrote:
>> Dear Johansson,
>>  Thanks for your reply. Your reply is very clear, that's just my
>> question. In fact, I am study a
>> MIPS binary file, but I cannot find any resource, so I turn to PowerPC
>> platform and try to get
>> clear understand about the string loading process.
> 
> I'm not sure how similar MIPS is to ppc ABI.

...and why not install the Denx ELDK for MIPS instead of trying to 
cross-deduce MIPS from PPC disassemblies?  At the level of detail you 
are asking questions, you are likely to get wrong or misleading results 
by using a totally unrelated CPU architecture.

Note that finding strings and the got (Global Offset Table) are related 
to position independent code (PIC).  Look at gcc documentation and read 
up on the -fpic options (multiple!).  Note that PIC is very CPU 
architecture dependent.

>> I want to ask according to your reply:
>> 1. fff0358c: 80 7e 80 00     lwz r3,-32768(r30)
>>    Is the -32768 stand for  " entry 0 in the .got table" ?  Why such a
>> translate in objdump?
> 
> It's not objectdump that do this it's the compiler that generate the
> code like this. r30 is a pointer to the GOT table but the pointer is
> located so that it's possible to use the full range of the 16 bit signed
> offset. that is if the GOT table only have one entry the r30 value would
> be pointing outside of the table but since it's accessed with a singed
> offset it will still work. 

Just to tag on my 2 cents: You (Wang Baohua) are asking very low level 
detailed questions about how the compiler and linker work on a u-boot 
list.  We use the tools, we don't necessarily understand the gory 
details (as long as they work, we're happy...).  You should be asking 
these questions on a gcc compiler/binutils list.  In addition, if you 
want to know MIPS details, ask MIPS questions with MIPS examples of MIPS 
*compiler* experts.  Given the detail level of your questions, the 
answers *will* be different between MIPS and PowerPC.

>> 2. I found the .got2 section in the U-boot.map, can you tell me how to
>> calc the right string address (traps.o) ?
>>    .reloc          0xfff34000     0x1578
>>    *(.got)
>>                      0xfff34000                _GOT2_TABLE_ = .
>>   *(.got2)
>>  .got2          0xfff34000       0x24 cpu/mpc8260/start.o
>>  .got2          0xfff34024       0x4c cpu/mpc8260/libmpc8260.a(traps.o)
> 
> ?? I thought this was obvious. to get the entry from the code take the
> offset value used in the load and subtract -32768 to get the offset into
> the .got2 section. at that address will be a 32 bit address that is the
> address of the string. 

FWIIW, the offset of 0x8000 is curious.  This implies to me that either 
this particular string is the first one in the GOT or something is wrong.

HTH,
gvb

[U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?

[Kenneth Johansson]

On Thu, 2008-06-05 at 20:17 +0800, wang baohua wrote:
> Dear kenneth,
>  Thanks for your quick reply. The first reply is clear.
> The second reply, I cannot calc this string address easily.
> According to your reply "at that address will be a 32 bit address that
> is the address of the string."
>  I search all the U-boot.bin, and CANNOT find any "00 02 B2 80" (that
> is the string "Call backtrace:") using hex search.

hmm where did this number came from?  is it the offset from the start of
the binary file ?? in that case it's obviously not going to be right the
data in the got table is absolute values and depend on where the final
link put the code. 

Lets do this the easy way. take the final u-boot elf file do not use
the .bin file. 

then do "objdump -D u-boot" this will list the data in the .got2
sections as instructions disregard that and look only at the values.



>  Can you give me the detail calc process:
>  1. offset value used in the load, this should be 0xFFEFFFE0 ??
no the offset was in clear text it was -32768 its a decimal number.

>  2. subtract -32768. this should be  - 0x32768 ? or -0x8000 ? or other
> value.
x= offset to load instruction and keep the sign 
x-(-32768) -> offset from start of .got2 section

in this case we have -32768 --32768 ->0 thus the first entry.

>  3. r30 is a pointer to the GOT table, it should be 0xfff34000 at
> 0xfff0358c exec ?? 

it should point +32768 from the start of .got2 section 

>  
> 
> 
> On Thu, Jun 5, 2008 at 5:53 PM, Kenneth Johansson
> <kenneth@southpole.se> wrote:
>         
>         On Thu, 2008-06-05 at 09:50 +0800, wang baohua wrote:
>         > Dear Johansson,
>         >  Thanks for your reply. Your reply is very clear, that's
>         just my
>         > question. In fact, I am study a
>         > MIPS binary file, but I cannot find any resource, so I turn
>         to PowerPC
>         > platform and try to get
>         > clear understand about the string loading process.
>         
>         
>         I'm not sure how similar MIPS is to ppc ABI.
>         
>         > I want to ask according to your reply:
>         > 1. fff0358c: 80 7e 80 00     lwz r3,-32768(r30)
>         >    Is the -32768 stand for  " entry 0 in the .got table" ?
>          Why such a
>         > translate in objdump?
>         
>         
>         It's not objectdump that do this it's the compiler that
>         generate the
>         code like this. r30 is a pointer to the GOT table but the
>         pointer is
>         located so that it's possible to use the full range of the 16
>         bit signed
>         offset. that is if the GOT table only have one entry the r30
>         value would
>         be pointing outside of the table but since it's accessed with
>         a singed
>         offset it will still work.
>         
>         > 2. I found the .got2 section in the U-boot.map, can you tell
>         me how to
>         > calc the right string address (traps.o) ?
>         >    .reloc          0xfff34000     0x1578
>         >    *(.got)
>         >                      0xfff34000                _GOT2_TABLE_
>         = .
>         >   *(.got2)
>         >  .got2          0xfff34000       0x24 cpu/mpc8260/start.o
>         >  .got2          0xfff34024       0x4c
>         cpu/mpc8260/libmpc8260.a(traps.o)
>         
>         
>         ?? I thought this was obvious. to get the entry from the code
>         take the
>         offset value used in the load and subtract -32768 to get the
>         offset into
>         the .got2 section. at that address will be a 32 bit address
>         that is the
>         address of the string.
>         
>         > thanks!
>         
>         
> 

[U-Boot-Users] Question About how the CPU find the right string address in U-boot binary file ?

[Wolfgang Denk]

In message <1212680342.7271.32.camel@localhost.localdomain> you wrote:
> 
> >  I search all the U-boot.bin, and CANNOT find any "00 02 B2 80" (that
> > is the string "Call backtrace:") using hex search.
> 
> hmm where did this number came from?  is it the offset from the start of
> the binary file ?? in that case it's obviously not going to be right the
> data in the got table is absolute values and depend on where the final
> link put the code. 

Speculation that he might actually be on a MIPS box, and that this
might eventually be running in little endian mode, he might eventually
have byte order issues.


Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Work 8 hours, sleep 8 hours; but not the same 8 hours.