|Summary:||GCC complains "FATAL:Section too large"|
|Product:||iOS||Reporter:||Sebastien Pouliot <sebastien>|
|Component:||Mono runtime / AOT compiler||Assignee:||Zoltan Varga <vargaz>|
|Severity:||enhancement||CC:||balebaron, ddunkin, deleted, dominic, felix, gouri.kumari, grant.macklem, heavycrag, john.miller, kirk_klobe, kumpera, luigisag, lupus, miguel, mono-bugs+monotouch, nathan.curtis, nicklas.petersson, pj.beaman, rolf, svoitsekh, vargaz|
|Target Milestone:||Future Cycle (TBD)|
|Tags:||Is this bug a regression?:||---|
|Last known good build:|
Description Sebastien Pouliot 2011-09-28 10:21:16 UTC
FATAL:Section too large, can't encode r_address (0x1210368) into 24-bits of scattered relocation entry
Comment 2 Zoltan Varga 2011-09-28 10:38:07 UTC
It probably means the application is huge.
Comment 3 Sebastien Pouliot 2011-09-28 10:53:45 UTC
Zoltan: "When compiling it in Windows it gets about 7 Mb large" (from assistly)
Comment 4 Brian LeBaron 2011-11-04 17:03:15 UTC
We are seeing this as well. FATAL:Section too large, can't encode r_address (0x1026238) into 24-bits of scattered relocation entry
Comment 5 Brian LeBaron 2011-11-14 12:49:59 UTC
We are still seeing this issue. The only way we can get around it is to compile with the llvm option on. This prevents us from being able to debug on the device, which can be extremely frustrating. Any progress being made with this? I'm happy to provide any information needed about our setup.
Comment 7 Brian LeBaron 2011-11-16 16:12:10 UTC
This is an excerpt from the build log showing the error message: Process exited with code 1, command: /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++ -gdwarf-2 -miphoneos-version-min=4.0 -arch armv6 -std=c99 -I/Developer/MonoTouch/SDKs/MonoTouch.iphoneos.sdk/usr/include -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk -c /var/folders/G4/G4sImOoZGJCQlBGMhWeMJU+++TY/-Tmp-/tmp213a7d85.tmp/Sketch.Busi.dll.6.s -o /var/folders/G4/G4sImOoZGJCQlBGMhWeMJU+++TY/-Tmp-/tmp213a7d85.tmp/Sketch.Busi.dll.6.o -DDEBUG /var/folders/G4/G4sImOoZGJCQlBGMhWeMJU+++TY/-Tmp-/tmp213a7d85.tmp/Sketch.Busi.dll.6.s:unknown:FATAL:Section too large, can't encode r_address (0x113ab88) into 24-bits of scattered relocation entry
Comment 8 Rolf Bjarne Kvinge [MSFT] 2011-11-16 16:26:24 UTC
Brian, Sorry about this, but if you could upload all the assemblies you have, it would make it a lot easier to try this (I can likely figure it out anyway, but it would definitively help having all the assemblies since otherwise I'd have to write mocked versions for those I don't have).
Comment 11 Rolf Bjarne Kvinge [MSFT] 2011-11-16 18:37:13 UTC
Thanks for the test case, we were able to reproduce it now. Unfortunately the initial guess is correct, it is a matter of size. The assembly in question is not that big, 2.1 mb, but the AOT compiler generates a 100mb file with arm assembly and when using GCC to compile that assembly file to an object file we hit a 16mb size limit on the generated code (this is a limitation in the arm object file format we can't do anything about). The first thing you should ensure is that you're linking all assemblies, if you're not doing that it might very well fix the problem. If that's not enough or you're already doing it the second thing you can do is to split the assemblies where this happens into smaller assemblies (which is not a good nor easy workaround of course). We're discussing ways to fix this in better ways, but it's not easy/small fixes so it will take some time until we get it done.
Comment 12 Brian LeBaron 2011-11-16 18:45:46 UTC
What I sent you was not linked. I tried setting it to link all and it builds without any errors but that build fails to run with the previously mentioned "segmentation fault 11" on launch. Which was determined to be caused by thumb instructions sneaking there way into our static lib. I'm going to take closer look at how we are building the static lib for our project. I know for a fact that compile for thumb is set to off.
Comment 13 Rolf Bjarne Kvinge [MSFT] 2011-11-16 18:48:06 UTC
Right, that thumb issue has (hopefully) been resolved, the fixes are being tested now and should get into the next MT release.
Comment 14 Brian LeBaron 2011-11-21 11:15:03 UTC
I've found the source of the thumb instructions in our static lib and have made sure they are no longer being included (otool). It builds fine but when I go to run it on a device I get the following error: Job appears to have crashed: Illegal instruction: 4
Comment 15 Rolf Bjarne Kvinge [MSFT] 2011-11-22 18:05:33 UTC
Brian, my guess would be that the additional mtouch arguments aren't correct. Even if that's not the case it's not this bug, so please open a new bug report for it with a test case.
Comment 16 Miguel de Icaza [MSFT] 2012-01-03 13:41:44 UTC
From the comments it looks like this bug was fixed, but a separate issue "Illegal Insturction 4" needs to be filed. Closing for now.
Comment 17 Rolf Bjarne Kvinge [MSFT] 2012-01-03 14:24:13 UTC
The comments are confusing, this bug hasn't been fixed (comment #11 is about this bug, the ones after that one are not).
Comment 18 Nathan Curtis 2012-05-02 20:59:54 UTC
Is there any update or ETA on this bug? Last night, I had to implement this fix, but my project relies pretty heavily on reflection, and a bunch of necessary symbols got stripped out because they are never referenced directly. Fortunately, there is a step I can take now that isn't all that painful to break up my assemblies, but I'm worried that will only work as a stopgap (I'm porting a rather large project to the iPad), and that one of my assemblies will end up growing too large for this boundary again, at which point I'll be quite stuck indeed.
Comment 19 Rolf Bjarne Kvinge [MSFT] 2012-10-22 07:52:35 UTC
*** Bug 7499 has been marked as a duplicate of this bug. ***
Comment 20 Grant Macklem 2012-12-04 11:02:39 UTC
We are seeing this same problem when trying to build a debug build for the device. Not being able to debug on the device is a nuisance now, but we are only in the investigation phase of a new app. It will be a huge problem once we start porting the majority of our code to MonoTouch. FATAL:Section too large, can't encode r_address (0x10eaee8) into 24-bits of scattered relocation entry
Comment 21 Rolf Bjarne Kvinge [MSFT] 2012-12-04 18:05:32 UTC
Grant, try enabling the managed linker (in the project's options, iPhone Build page, select "Link SDK assemblies" or "Link all assemblies" for "Linker behavior"), it will usually work around this problem quite well.
Comment 22 Grant Macklem 2012-12-06 13:46:03 UTC
Hi Rolf, We currently have our iPhone Build settings as "Link SDK assemblies only." Changing it to "Link all assemblies" builds correctly. Evidently we tried this before, but it causes our app to crash on launch due to our extensive use of MEF and composition. Would it be possible for the linker to look at other attributes than the [Preserve] attribute to keep these pieces around? Maybe the Export attribute could imply Preserve? Others on the team have made a few attempts to mark all our needed pieces as [Preserve], but none has been successful thus far.
Comment 23 Sebastien Pouliot 2012-12-06 14:03:39 UTC
I do not recall if MEF uses another [Export] attribtue - but the one from MonoTouch cannot be changed to [Preserve]. OTOH there's several ways to customize the linker, [Preserve] is only one of them. http://spouliot.wordpress.com/2012/04/27/linker-versus-customization/ You can also use "Link All" and then turn off linking for one (or more) specific assemblies using --linkskip=ASSEMBLY (without .dll or .exe). You can also use an XML file instead of [Preserve]. That's useful when you do not have the source code (to modify) for the code you want to preserve (e.g. MonoTouch provided assemblies or 3rd party code). In your case you could write a simple tool that create entries for all your [Export] code (and re-run it when your assembly change and before using mtouch).
Comment 24 Felix Collins 2012-12-06 16:33:21 UTC
The latest ServiceStack.Text will not work on monotouch because of this issue. Splitting it into multiple assemblies is not trivial because there is no clear file dependency structure within the project. Any other workarounds suggested?
Comment 25 Rolf Bjarne Kvinge [MSFT] 2012-12-06 16:50:09 UTC
Felix, the current workarounds are to enable the managed linker (comment #21), enable LLVM (comment #5), split the assembly into multiple smaller assemblies, or remove/comment out/ifdef out pieces of code from the offending assembly you know you're not going to use.
Comment 26 Felix Collins 2012-12-17 15:13:33 UTC
What is the timeline for getting this fixed? We are having to drop using ServiceStack in our project because the latest touch release 3.85 is way behind the head and has bugs, we can't use the latest head because it will not compile due to this bug. I see this has been open for over a year which is quite a long time for a bug marked High critical.
Comment 27 Felix Collins 2012-12-17 16:09:55 UTC
Actually, I'm not sure if this is the same issue now. I get... "Error MT3001: Could not AOT the assembly...." I've opened another ticket https://bugzilla.xamarin.com/show_bug.cgi?id=9002
Comment 28 Miguel de Icaza [MSFT] 2012-12-17 16:40:20 UTC
Felix, Fixing this problem requires a fairly large rewrite of our code generator, which is why the workaround is to link your assemblies. Without linking, you are including very large swats of code that are never used. So you should always use linking. If you have specific problems with linking, you could look into providing a link descriptor to instruct the linker to not remove specifics bits of code, see: http://docs.xamarin.com/ios/Guides/Advanced_Topics/Linker#Custom_Linking For more details.
Comment 29 Rolf Bjarne Kvinge [MSFT] 2013-05-14 09:57:07 UTC
*** Bug 11274 has been marked as a duplicate of this bug. ***
Comment 31 PJ 2013-11-19 16:44:40 UTC
This bug was targeted for a past milestone, moving to the next non-hotfix active milestone.
Comment 32 Sebastien Pouliot 2014-03-19 13:07:50 UTC
*** Bug 9002 has been marked as a duplicate of this bug. ***
Comment 33 Rolf Bjarne Kvinge [MSFT] 2014-04-29 04:51:21 UTC
*** Bug 18860 has been marked as a duplicate of this bug. ***
Comment 34 Rolf Bjarne Kvinge [MSFT] 2014-05-12 07:07:26 UTC
*** Bug 19605 has been marked as a duplicate of this bug. ***
Comment 35 Rolf Bjarne Kvinge [MSFT] 2014-06-25 18:01:28 UTC
*** Bug 20879 has been marked as a duplicate of this bug. ***
Comment 36 Rolf Bjarne Kvinge [MSFT] 2015-03-05 08:48:33 UTC
*** Bug 15904 has been marked as a duplicate of this bug. ***
Comment 37 Sebastien Pouliot 2015-04-06 09:37:37 UTC
*** Bug 28700 has been marked as a duplicate of this bug. ***
Comment 38 GouriKumari 2016-01-11 17:58:19 UTC
Workarounds are provided for this issue and based on comment #28, I am moving the target milestone.
Comment 39 Rolf Bjarne Kvinge [MSFT] 2016-02-05 13:49:03 UTC Comment hidden (obsolete)
I'm closing this bug, because there is no general solution here. We can always make improvements to our AOT compiler that will decrease the executable size (which we do), but that only means we'll hit the limit with more managed code, not that we've removed the limit. For projects that run into this problem, please file separate bug reports for each of them (since each project is different and will exercise the codegen in different ways), and we'll have a look and see if our codegen can be improved for each particular project.
Comment 40 Sebastien Pouliot 2016-02-05 14:08:02 UTC Comment hidden (obsolete)
Re-opening as it has proven useful to track duplicates in a single place. Note that a lot of data is historical (e.g. gcc->clang, it's a 32bits-only issue) and some comments are not related to the bug.
Comment 41 Rolf Bjarne Kvinge [MSFT] 2017-01-10 17:01:57 UTC
Another potential workaround for apps running into space issues like this showed up in bug #51226: add "--mono:framework" to the additional mtouch arguments, and the mono runtime will be included as a framework in the app, instead of linked statically into the main executable.
Comment 42 Rolf Bjarne Kvinge [MSFT] 2017-01-10 17:09:08 UTC
*** Bug 51226 has been marked as a duplicate of this bug. ***
Comment 43 Sebastien Pouliot 2017-01-17 19:46:26 UTC
*** Bug 23191 has been marked as a duplicate of this bug. ***