Unable to run run-time loaded code on ZedBoard

[Chris Johns]

On 20/10/2015 8:20 am, Patrick Gauvin wrote:
> Hi Chris,
> 
>> Simple question first. Was the load flagged as having unresolved externals?
> 
> No, the "dlinfo (handle, RTLD_DI_UNRESOLVED, &unresolved)" call
> (dl-load.c:40) indicates that all externals are resolved.
> 

Excellent.

>> Is this the correct address? Is this the address in the base image?
> 
> 0x119528 is the correct address for printf.
> 

Good.

>> I assume the base image and the o are built the same so should the
>> bottom bit of the address be set for thumb mode? It has been a long time
>> since looked at the specific detail.
> 
> The bottom bit should be set when a bx/blx (with register argument) to
> THUMB code is made, and I see it here when the blx to "rtems_main" is
> made:
> 
> (gdb) disas/r  $pc-8,$pc+8
> Dump of assembler code from 0x104686 to 0x104696:
>    0x00104686 <dl_load_test+182>:       41 f2 94 41     movw    r1,
> #5268       ; 0x1494
>    0x0010468a <dl_load_test+186>:       c0 f2 20 01     movt    r1, #32
> => 0x0010468e <dl_load_test+190>:       98 47   blx     r3
>    0x00104690 <dl_load_test+192>:       b8 60   str     r0, [r7, #8]
>    0x00104692 <dl_load_test+194>:       bb 68   ldr     r3, [r7, #8]
>    0x00104694 <dl_load_test+196>:       02 2b   cmp     r3, #2
> End of assembler dump.
> (gdb) p/x $r3
> $10 = 0x2138f9
> 
>> If you disassemble a piece of code in the base image that calls printf
>> what instruction do you see?
> 
> This at is dl-load.c:45:
> (gdb) disas /r $pc,$pc+32
> Dump of assembler code from 0x10464a to 0x10466a:
> => 0x0010464a <dl_load_test+122>:       4f f2 30 70     movw    r0,
> #63280      ; 0xf730
>    0x0010464e <dl_load_test+126>:       c0 f2 11 00     movt    r0, #17
>    0x00104652 <dl_load_test+130>:       39 69   ldr     r1, [r7, #16]
>    0x00104654 <dl_load_test+132>:       7a 69   ldr     r2, [r7, #20]
>    0x00104656 <dl_load_test+134>:       14 f0 67 ff     bl
> 0x119528 <printf>

Yes it is and gdb seems to have stripped the bit and this is the same as
the original print out. Maybe it is actually set. Is it possible to get
a similar disassemble with for the loaded object file, ie the hex dump
of the op codes and the decoded output?

> 
>> Note, ARM veneers is an outstanding task I need to complete.
> 
> The bl instructions to printf inside the loaded code are within range
> (16 MB for the 32bit T32 bl) so I don't think this application
> requires veneers. I will keep this in mind for the future, though.

Do you have a special option on? I thought the default was 24bit.

Chris