Login at Kodi Home

henke66 · 2012-05-21, 10:21

I was trying to find some information about the showstopper for atv2/ios5 on mainline and thought this was it. I must say it is not that trivial to find that information around here.
The problem how it was described here didn't sound impossible to track, Run-time problem is probably more difficult.
Sure I'm interested!
For starters, I'm a professional software developer since more than 2 decades but I've treated everything from Apple as paria until I found out that this little nice atv2 ran xbmc.
ATV/XBMC with live-TV and spotify fits my needs perfectly! I must also say that it is running very stable this couple of weeks I've had it in my hands. Great work!

Would it be a good idea to create a thread to discuss the "real" problem?
If we share the findings so far maybe we can track this down with joint force.
Since my experiance regarding atv/ios/xbmc is limited and I may ask "stupid" questions, please try to avoid answering with retoric question. That doesn't benefit anyone. So spread the information and I'm sure this can be solved!

Keep up the excellent work!

davilla · (This post was last modified: 2012-05-21, 19:34 by davilla.)

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.

henke66 · 2012-05-21, 20:54

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

So you mean that the diference between atv and iphone is that in atv the xbmc application is actually a dynamicly loaded library and on iphone it is a regular application?
ffmpeg is a dynamically loaded library in both cases, right?
So problem occurs when a dylib uses another dylib?

davilla · 2012-05-21, 21:33

No, in Eden ffmpeg was dlopen'ed in both cases(ios/atv2) but Eden has the patch. So all is good there.

In mainline code, we changed from using dylibs to linking static libs for ffmepg (an issue with actually building an ffmpeg as an arm dylib).

Now ffmpeg becomes part of xbmc binary and there's no need to dlopen it. BUT in iOS, xbmc is a real app, in atv2 it is a bundle (frapp) that frontrow loads using dlopen. So under atv2, it's the same dlopen issue regardless of if frontrow does the dlopen or if xbmc would do the dlopen.

Any bundle that contains references to global symbols in .text segments from the assembler code that require fixups to their offset symbol address. If you dlopen it, bang. kernel panic. This also applies if the loader loads the dylib too, so make a simple binary app that links to ffmpegs dylibs, run it and bang, kernel panic.

henke66 · 2012-05-22, 07:22

So if I understand correctly, the main problem is that ffmpeg can't be used as a dylib on arm/neon.
What does ffmpeg guys say about it? Have you got any feedback?

davilla · 2012-05-22, 08:24

no, there are two issues, 1) ffmpeg will not compile as a dylib. 2) ffmpeg used in any dylib/bundle will panic the kernel when loaded. 1) is not so important, 2) is a deal breaker for atv2.

**virtuallysafe** · 2012-05-22, 11:39

Hi Guys,

Its really interesting to understand the issue here, thanks Davilla.

I apologise for injecting myself into conversation and please forgive my significant ignorance however, for those willing, is it possible to replace Frontrow with XBMC? Would XBMC then be loaded as a ‘real app’ and thus mitigate the requirement for it to be dlopen'ed by Frontrow?

**Memphiz** · (This post was last modified: 2012-05-22, 11:55 by Memphiz.)

Yes that would be theoretically possible by using MobileX - but this was only a proof of concept by the jailbreak devs and isn't developed any further so this isn't a real option. (though it needs adaptions to XBMC and it was slow when we gave this a shot some month ago).

This has to be fixed in ffmpeg.

Henke66 - i think you still missed the part where we told that we are not using a dylib anymore. Wink

We are linking statically now. Basically davilla described the problem very well imho. I'll try to get one of the libav maindevs to look into this - hold your breath Wink

henke66 · 2012-05-22, 21:22

I do understand that you currently link it statically. But if the ffmpeg would build as a dylib and behave as one, I beleive the problem would be solved. I don't know, but isn't it reasonable that the ffmpeg would build as a dylib on arm. I beleive this is normal on other platforms.
Is this an active decission of ffmpeg to not support dylib on arm?
This should probably be an issue on other arm platforms as well. But on other platforms they can choose to make a static link.
I also understand that even if we make a static link of ffmpeg in the atv2-xbmc bundle it still doesn't matter since the hole shebang will be dynamically loaded anyway.

davilla · 2012-05-22, 22:19

* davilla slams his head on his desk, multiple times. dyloading ffmpeg code is the issue, does not matter if it's a ffmpeg built dylib or a static link into a bundle that is dyloaded. Dyload it, bang, kernel panic.

davilla · 2012-05-23, 05:55

humm, how did I make everything red Smile

DDDamian · 2012-05-23, 06:28

It was your tone of typing/head-banging Tongue

**Martijn** · 2012-05-23, 07:06

(2012-05-23, 05:55)davilla Wrote: humm, how did I make everything red

It's the blood... Tongue

henke66 · 2012-05-23, 07:58

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

DDDamian · 2012-05-23, 08:10

ow - i think baiting Davilla with "How to write shared libraries" is like waving the red flag at the bull (or maybe the spear in the side)