On Sun, Mar 13, 2011 at 12:47:22PM -0700, Chris Lattner wrote:
>
> On Mar 13, 2011, at 12:05 PM, Jack Howarth wrote:
>
> > On Sun, Mar 13, 2011 at 11:55:02AM -0700, Chris Lattner wrote:
> >>
> >> On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
> >>
> >>>> Yes, I agree that this is a better solution. This error was put into
> >>>> the linker to detect some overflow conditions for part of the code that
> >>>> expected the section number to only be a byte. It is likely that
> >>>> "things worked" only out of luck before.
> >>>>
> >>>> -Chris
> >>>
> >>> Chris,
> >>> Is there any documentation or example code on how to properly use
> >>> subsections in mach-o?
> >>> My fear is that we are moving from one poorly documented technique to
> >>> another which may well
> >>> have it own slate of hidden bugs.
> >>
> >> I'm not sure what you mean here Jack. ld64 is open source on the darwin
> >> page, and if you have all the developer bits installed, the format is
> >> "documented" in /usr/include/mach-o/. It's pretty clear all around that
> >> you can only have 256 sections.
> >>
> >> -Chris
> >
> > Chris,
> > The mach-o reference has a cryptic mention of MH_SUBSECTIONS_VIA_SYMBOLS in
> >
> > http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
> >
> > MH_SUBSECTIONS_VIA_SYMBOLS—The sections of the object file can be divided
> > into individual blocks. These blocks are dead-stripped if they are not used
> > by other code. See Linking for details.
>
> Right, "subsections via symbols" is the concept of slicing up a section into
> "atoms" based on public labels. The linker uses this to do dead code
> elimination etc. I don't think this helps you at all though.
>
> I don't understand why you can't put arbitrary data into a single section.
> This is what the -sectcreate flag to the linker does, so it is simple,
> already supported, and tested.
Chris,
Sure, aasuming we can find a victim to do the unncessary coding. Again, Nick
left us with the impression that n_sect was
only sanity checked in the case of symbols being present in the sections. This
isn't the case. I've used the FSF gcc
LTO for very large projects as well as routinely bootstraping FSF gcc with LTO
an it has worked perfectly under Xcode
3.2.5. So this isn't a fragile situation as we never output more than 255
sections with symbols in the final linkage.
The annoyance witnessed here is that Apple isn't following it's own mach-o
documentation as it exists. However I agree
it is in the best interest for us to recode this in order to protect ourselves
from further improper Xcode changes
in the future. It will be interesting to see if this ends up causing misery for
other developers who have relied
on Apple's mach-o documentation being honored for their own coding of
additional non-symbol containing sections.
Jack
>
> -Chris
>
> >
> > Although I don't think this helps us at all because none of the GNU_LTO
> > sections contain symbols. This is why I
> > am still perplexed by this assembler change. We followed the rules Nick
> > suggested of placing all of these GNU_LTO
> > sections at the end of the file and none contain symbols. In that case, it
> > would really seem that the assembler is
> > now blindly counting sections without respect to whether any of them
> > actually contain symbols.
> > Jack
