2012-05-23, 09:22
Is that a good or bad thing? Should i be concerned?
Maybe he will do magic when he sees red (or writes red).
Maybe he will do magic when he sees red (or writes red).
(2012-05-23, 07:58)henke66 Wrote: I found an extensive document about shared libraries (aka dynamic linked libraries), which I haven't had time to read yet.
If you wan't to understand the implications about dynamic linking this seems to be a great reference.
How To Write Shared Libraries
(2012-05-23, 16:22)davilla Wrote: what was that thing about grandmothers and sucking eggs and by the way, darwin is not ELF.First, I was not trying to be rude! And when I wrote 'you' in the post about shared libraries, it was not adressed to you personnaly but to the community, there might be others reading as well.
(2012-05-23, 18:59)davilla Wrote: lighten up, cowboy. I tend to joke a lot
Darwin uses Mach object file format, Linux and some others use ELF. The difference is huge and cannot be explained in a few simple sentences.
As an example, darwin (Mach object file format) can support multiple archs in the same file and the loader will make sure the correct arch is loaded. ELF cannot support multiple archs in the same file.
(2012-05-26, 07:39)linusyang Wrote:(2012-05-23, 18:59)davilla Wrote: lighten up, cowboy. I tend to joke a lot
Darwin uses Mach object file format, Linux and some others use ELF. The difference is huge and cannot be explained in a few simple sentences.
As an example, darwin (Mach object file format) can support multiple archs in the same file and the loader will make sure the correct arch is loaded. ELF cannot support multiple archs in the same file.
Hi, davilla. Is there any chance to make a branch with the old ffmpeg library so that we could get the build to work on the device temporarily?
(2012-05-21, 19:34)davilla Wrote: 1st, on an real iOS device does not have this problem as XBMC is a real app and as such it nor ffmpeg is dyloaded.
dlopen() crashes the system when loading library that contains references to global symbols from the assembler code (neon). Starting from iOS 5 dlopen() is no longer able to write the symbol addresses to the .text segment during the library load (required to offset symbol address). We used a patch that modified the neon files in FFMpeg to use relative symbol addresses that do not require modification of the .text segment during load. That patch no longer applies and there are more areas to fix up.
Generally if you grep ffmpeg's arm asm code, I think (limited arm-asm-fu) anything that does movrel with an X(xxxx) var would need patching if the X(xxxx) var references a global.
This is very similar to a ppc patch that went into ffmpeg about two years ago to handle an Apple bork under OSX 10.5.
See https://github.com/xbmc/xbmc/blob/Eden/l...iOS5.patch
I have a test app for testing this, much quicker than building xbmc, uploading, test. specially since xbmc's frapp gets loaded each time on boot and you generally have to re-jailbreak to fix. With the test app, the kernel will panic and you just reboot.
00000064 e3018c2c movw r8, :lower16:0x1ca0-0x6c+0xfffffff8
00000068 e3408000 movt r8, :upper16:0x1ca0-0x6c+0xfffffff8
.macro movrel rd, val
movw \rd, #:lower16:\val
movt \rd, #:upper16:\val
.endm
(2012-05-30, 23:17)davilla Wrote: val is still wrong because the loader cannot fix up the address, infact you will kernel panic miles before that code even runs. you die in loading the dyload, not running the asm code.So you are saying that the kernel panic occurs when dlopen is trying to patch the code according to the relocation entries.
(2012-05-31, 21:43)davilla Wrote: yes.
global in .text sections. see my original post
no and iOS apps are not permitted to dlopen, unless the change might be in darwin sources.
yes, c/c++/objc, the compiler knows what to do.
.macro movrel rd, val
movw \rd, #:lower16:\val
movt \rd, #:upper16:\val
.endm
const int myConstVar = 47;
int myVar;
int myFunc(void)
{
myVar = myConstVar;
return myVar;
}
(__TEXT,__text) section
_myFunc:
00000000 e30002c4 movw r0, :lower16:0x2d8-0xc+0xfffffff8
00000004 e3a0102f mov r1, #47 @ 0x2f
00000008 e3400000 movt r0, :upper16:0x2d8-0xc+0xfffffff8
0000000c e79f0000 ldr r0, [pc, r0]
00000010 e5801000 str r1, [r0]
00000014 e3a0002f mov r0, #47 @ 0x2f
00000018 e12fff1e bx lr
movrel r2, X(ff_cos_16)
00000190 e3002000 movw r2, :lower16:_ff_cos_16
00000194 e3402000 movt r2, :upper16:_ff_cos_16
00000194 False hi/arm True HALF False _ff_cos_16
False hi/arm False PAIR False other_half = 0x0000
00000190 False lo/arm True HALF False _ff_cos_16
False lo/arm False PAIR False other_half = 0x0000
00000008 False hi/arm n/a HALFDIF True 0x000002d8
False hi/arm n/a PAIR True 0x0000000c other_half = 0x02c4
00000000 False lo/arm n/a HALFDIF True 0x000002d8
False lo/arm n/a PAIR True 0x0000000c other_half = 0x0000
00000758 False long True VANILLA False _ff_cos_16