ffmpeg patch

henke66 · 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).

**davilla** · 2012-05-23 16:22

(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

what was that thing about grandmothers and sucking eggs Smile

and by the way, darwin is not ELF.

henke66 · 2012-05-23 18:05

(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.

I really don't understand if you rather be left alone here or if it is allowed to come up with ideas on how to solve the problem.

If we are still discussing the problem here, my thinking (wthout knowing) is that the assembler code preventing the ffmpeg to build as a dylib, is the same that will cause the kernel panic when it is statically linked.
So what I was suggesting earlier is that the ffmpeg team need to make changes to their code so that it will be able to use as a dylib. If they manage with that it would probably work also for the ATV2. If you are of another opinion, please explain...

So if darwin is not elf, would you care to explain the difference?

**davilla** · 2012-05-23 18:59

lighten up, cowboy. I tend to joke a lot Smile

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.

linusyang · 2012-05-26 07:39

(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?

Cranial · 2012-05-26 08:07

(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?

Not a coder, but I think this would be more trouble than it's worth. I assume a lot of code has changed with the implementation of the new ffmpeg, so time spent getting it working with the old version is time not spent trying to fix mainline to work with the ATV2.

Eden still works, and works well....

henke66 · 2012-05-30 21:20

(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.

I have spent some time looking at this...I guess the relocation is not a problem for c-files, right?
When looking at a disassembled c-file the instructions for loading a global variable is using a pair of movw and movt like :

Code:

00000064    e3018c2c    movw    r8, :lower16:0x1ca0-0x6c+0xfffffff8

00000068    e3408000    movt    r8, :upper16:0x1ca0-0x6c+0xfffffff8

If this works fine we could use the same instructions in the assembler code. Since the problem is caused in the movrel macro, I beleive we could use the following implementation for it in ffmpeg/libavcodec/arm/asm.S

Code:

.macro movrel rd, val

        movw \rd, #:lower16:\val

        movt \rd, #:upper16:\val

.endm

This should take care of the problem in all locations. What is your opinion? Am I missing something? Is this worth trying?

**davilla** · 2012-05-30 23:17

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.

henke66 · 2012-05-31 21:25

(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.
Is it known what kind of relocations that will fail?
Is the change in ios5/dlopen documented? Bbecause there is one, right?

Relocation seems to be working well for c-files, so my theory is that we need to look at the difference between the relocation tables for a typical c-file and a neon-assembler one.

**davilla** · 2012-05-31 21:43

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.

henke66 Junior Member Posts: 46 Joined: May 2012 Reputation: 0	2012-05-23 09:22 Post: #31 Is that a good or bad thing? Should i be concerned? Maybe he will do magic when he sees red (or writes red). (This post was last modified: 2012-05-23 15:48 by henke66.)
	find quote

davilla Team-XBMC Developer Posts: 10,399 Joined: Feb 2008 Reputation: 58	2012-05-30 23:17 Post: #38 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. MediaInfo : http://mediainfo.sourceforge.net/ Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
	find quote

davilla Team-XBMC Developer Posts: 10,399 Joined: Feb 2008 Reputation: 58	2012-05-31 21:43 Post: #40 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. MediaInfo : http://mediainfo.sourceforge.net/ Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
	find quote