From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by mx.groups.io with SMTP id smtpd.web12.27888.1628799924568831306 for ; Thu, 12 Aug 2021 13:25:25 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=mOg1btvG; spf=pass (domain: posteo.de, ip: 185.67.36.66, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 2481E240105 for ; Thu, 12 Aug 2021 22:25:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1628799915; bh=HN4VNQ5DpA0yU/MwMhdS/t6vyg65jic2JtaHSUs32ds=; h=Subject:From:To:Cc:Date:From; b=mOg1btvGLSOEHxPez3VSe6vr4ZuEiA3+usNmixOqj8dhXgzyZq/PnJsNZ4yn4xecI 1iwy9gstjvh34KI4IfCMgiGtqav0TFGXCTt03U3LJmLEWhhha34zeEDbqERUDp7OV8 KWNq2wRjROrgSVa0NM+uyWf3KwU91GEVlV1OjG7KjgdF+sl4Qxnen8VNc1ykTJ6lGA 9GRzyv9G93xnBBG9pcDKnemoRydEw+JXZ9VTcGSyUxEmq8hxTL9sAPvqDZgXPpod0l MXOd56jyE7Q/ZdI2p038YpGVHYpQqE5Nr1P+a4XMW0AaPqahnYKsWEWf+h06larE2Y EtcFRuQ3PGrIA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4GlyqF0JgNz6tmB; Thu, 12 Aug 2021 22:25:12 +0200 (CEST) Subject: Re: [edk2-devel] [PATCH v2 1/2] BaseTools: Define the read-only data section name per toolchain From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= To: Andrew Fish , edk2-devel-groups-io Cc: Bob Feng , Liming Gao , Yuwei Chen , Vitaly Cheptsov References: <252525969122e83d9fb9b83edc95c4f6dfd233b4.1628502434.git.mhaeuser@posteo.de> <7787F470-EEE0-4E13-93C1-508844167749@apple.com> <15D26D2D-D4E8-485A-B40F-A89B3C67BF37@apple.com> <215befc7-a214-7c1d-4bba-94442d3f56aa@posteo.de> <347E6A0A-EFD9-4CA4-BBD3-67F4714747F6@apple.com> <544f4fca-40e8-4273-7d28-a581caa814a2@posteo.de> <25E4F188-3573-445A-B355-ADB79BA4E452@apple.com> <2b8a9ab8-1019-1ade-cde3-f4492432dc1d@posteo.de> Message-ID: Date: Thu, 12 Aug 2021 20:25:12 +0000 MIME-Version: 1.0 In-Reply-To: <2b8a9ab8-1019-1ade-cde3-f4492432dc1d@posteo.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 12/08/2021 09:26, Marvin H=C3=A4user wrote: >>> The value of p is constant, so it can be placed in a constant data=20 >>> section. p points to a global variable, so if the compiler does not=20 >>> manage to somehow turn this into relative addressing (let's assume=20 >>> it does not), it needs to generate a relocation. This means the=20 >>> compiler cannot put it in __TEXT,__const, so it has to put it in=20 >>> __DATA,__const (of course it could put it in other __DATA sections,=20 >>> but let's assume the compiler agrees this should be read-only). The=20 >>> very same issue will arise and no matter the choice of the compiler,=20 >>> this will end up in .data. Do you agree? Or do we have some=20 >>> guarantee that Apple Clang cannot emit __DATA,__const? >> >> I don=E2=80=99t see your bigger point. The compiler is free to implement= as=20 >> it sees fit. Which section some code ends up in is more of an=20 >> implementation detail for the compiler, and we can=E2=80=99t really depe= nd on=20 >> that? > > Your point, rightfully, was that things that we request to be=20 > read-only (may) end up being read-write. My issue is that, if the=20 > compiler requests this pointer to be read-only (it may not, but also=20 > it may), our PE executable does not honour it either. __DATA,__const=20 > is a section for constant data, and we put it into a read-write=20 > section. The bigger point is, whenever the compile stack wants=20 > something read-only (be that NASM or be that Apple Clang, anything=20 > really), we should actually ensure it is read-only. I can do that for=20 > only NASM by forcing the __TEXT,__const section name (at the cost of=20 > prohibiting relocs), but I do not know how to do it for Apple Clang.=20 > At worst we could take a hacked-ish solution, where all Mach-O=20 > segments are converted to PE/COFF sections - with the exception of the=20 > __DATA,__const section, which, if aligned on a segment alignment=20 > boundary, can be inserted between the two other parts .data is split=20 > into. I read in the XNU source that the ARM protection code does=20 > something roughly like this [1], but I'm really far from well-versed=20 > in the deep details of macOS. > > Sorry for this not being "integrated" in above text, but I found two=20 > more things while looking for citation 1. > > 1) Mach-O sections can be renamed, including the preceding segment=20 > name [2]. According to the very next line, the example actually=20 > creates a new segment. Does it allow merging into another, existing=20 > segment? What if I did something like: > > -Wl,-rename_section,__DATA,__const,__TEXT,__const2 > > or even > > -Wl,-rename_section,__DATA,__const,__TEXT,__const=20 (I cut the upper part of the quote to make some room...) Both worked as expected. > > i.e. can it merge two sections together? if __DATA,__const had data=20 > with relocs, would the renaming trigger the "no relocs" error of=20 > __TEXT, or does that happen before section renaming? Any chance it can=20 > be turned off? As feared, the error triggers. However I found a seemingly=20 not-so-well-known flag for Apple ld64 to disable it: "-read_only_relocs=20 suppress". In fact, it is already used for IA32 builds, but not for X64=20 builds? [1] I also noticed the extent of the XCODE5 "exceptions", e.g. duplicated=20 files [2]. The files seem to be out-of-sync, but interestingly the=20 XCODE5 version is the one that is more current and used in other=20 toolchain builds as well. So, maybe we can do the following? 1) Pass "-read_only_relocs suppress" for X64 and clean up any=20 XCODE5-specific workarounds for text relocations. 2) Use neither "__TEXT,__const" nor "__DATA,__const" for=20 NASM_RODATA_SECTION_NAME, but "__DATA_CONST,__const". Give it RNX=20 permissions. 3) Case-distinct between "generate standalone .rodata" and "merge=20 .rodata into .text". 3.1) case 1: Rename "__TEXT,__const" and "__TEXT,__cstring" to=20 "__DATA_CONST,__text_const" and "__DATA_CONST,__cstring" respectively. 3.2) case 2: Rename "__DATA_CONST,__const" to "__TEXT,__data_const". Rationales: 1) There is no such concept in PE/COFF, we can discard it and align with=20 PE/COFF and ELF toolchains. Allows ".rodata" merge into ".text". 2) There is no pre-existing segment for read-only data, so we create our=20 own with a naming convention taken from XNU. 3.1) Both former sections do not contain executable code, so we properly=20 enforce the separation introduced in 2). Choose unique names to not=20 reduce the object file separation. 3.2) Merge ".rodata" into ".text" in the same way ELF toolchains do.=20 Saves space and we get to keep read-only. I can test both cases work fine soon. > > 1.1) Actually, for the standalone .rodata section, we can just rename=20 > it to __DATA_CONST,__const, as I have seen elsewhere in XNU. No=20 > hacked-ish solution needed. :) > > 2) We actually can force the compiler to put data in the constant data=20 > segment [3]. This is of course not used in EDK II, and probably=20 > neither portable nor necessary, but an interesting detail. I really=20 > think we should honour it either way. > > I will likely try to get my hands on some sort of Apple development=20 > environment soon, but I cannot promise much right now. I think it=20 > really is better if I can test through all toolchains myself. If you=20 > release Apple Clang for Linux, I also won't complain of course. :)=20 I found a port of Apple ld64 for Linux. I get it's not "the real deal",=20 but all observed behaviour matches what I've seen so far from Apple=20 Xcode. Actually boots OVMF. :) A side note, seems like even latest mtoc gives .data RWX no matter what?=20 Ouch... Best regards, Marvin [1]=20 https://github.com/tianocore/edk2/blob/master/BaseTools/Conf/tools_def.temp= late#L2980-L2982 [2] https://github.com/tianocore/edk2/blob/0a6b303dcedb7af238ad485d545802befb79= 7b3a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerAs= m.nasm https://github.com/tianocore/edk2/blob/0a6b303dcedb7af238ad485d545802befb79= 7b3a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm > >> >>> >>>>>> We should double check what is happening for ELF on x86, ARM,=20 >>>>>> RiskV, etc. and do the same thing. I assume all the tools that=20 >>>>>> generate PE/COFF directly are good with .rodata? >>>>> They are not, that is the whole point of the patch in its current=20 >>>>> shape. .rodata is valid for ELF and Mach-O, PE/COFF needs .rdata. >>>>> >>>>>> I think it is likely as simple as dumping the EFL object file in=20 >>>>>> objdump or gdb for the given toolchain (like my Xcode example). >>>>>> >>>>>> TL;DR It looks to me like nasm does some SECTION translations=20 >>>>>> under the hood to make code portable, and I=E2=80=99d like to make s= ure=20 >>>>>> we capture those in the new NASM_RODATA_SECTION_NAME. If some one=20 >>>>>> is doing a security review having NASM_RODATA_SECTION_NAME is=20 >>>>>> going to imply that a .rodata section is being used by that=20 >>>>>> specific toolchain, and I think that is much worse than the=20 >>>>>> current =E2=80=9Cmagic=E2=80=9D behavior in nasm. We are much better= off=20 >>>>>> explaining what is really happening, since it is not very obvious. >>>>> I feel like I'm too tired to get the point. Do you mean you want=20 >>>>> comments whenever this section name is used? Or comments in=20 >>>>> tools_def? >>>>> >>>> I think I=E2=80=99d settle for a more descriptive commit comment that= =20 >>>> better defines what the define means like I mentioned in the other=20 >>>> mail. >>> >>> Hmm no, we can do that too, but in that case I really want comments=20 >>> in the code. tools_def is not really documented at all, maybe it is=20 >>> time to introduce an example comment so at least new things get=20 >>> commented? Maybe just the start of a macro list. Relying on "git=20 >>> blame" to figure out simple things is rather awful. >>> >>> One more thing from another thread: Yes, the new macro should refer=20 >>> to object file section naming. I want this patch to get object file=20 >>> sections proper and sound. From there on we can fix the linking=20 >>> stage to emit proper and sound executables in a later patch. >>> >> >> OK then please refactor the commit message to make it clear that this=20 >> patch is to get the correct section in the object files, and work is=20 >> still need to get this into executable images. > > Sure. > >> >> For Xcode you can make it __DATA__,__const since that is the closest=20 >> thing to read only data and I think that is your intent. > > I would like to do that, but only if we can ensure __DATA,__const is=20 > merged into .text, or is a separate RNX section. > >> >> GenFW is part of EDKII BaseTools and mtoc is part of the open source=20 >> CCTOOLS project and both those tools would need to be modified to=20 >> create a .rodata section in PE/COFF. > > Yes, that should not be a big problem. Remaining issues for me: > 1) How to merge __DATA,__const into .text, or how to emit a standalone=20 > .rodata section, for Xcode-based toolchains? (Some ideas above, will=20 > ping Vitaly soon as well) > 2) How to submit modified mtoc? Any chance it could be maintained in=20 > EDK II like GenFw? (Would be nice if you could provide some insight) > 3) How to merge .rdata into .text for MSVC? (I will try to research=20 > this soon-ish, but no promises) > 4) How to design a toggle for the platform maintainer to choose=20 > between .text merge and standalone .rodata? > > Please note that I'm not asking you to research any of those questions=20 > (but 2) would be nice :) ), this is merely a summary of open points=20 > till the second stage (correct executables, not just correct object=20 > sections) can be properly approached. > > Thanks for your time and insight! > > Best regards, > Marvin > > > [1]=20 > https://github.com/apple/darwin-xnu/blob/a1babec6b135d1f35b2590a1990af3c5= c5393479/osfmk/arm/arm_vm_init.c#L318-L324 > > [2]=20 > https://github.com/apple/darwin-xnu/blob/2ff845c2e033bd0ff64b5b6aa6063a1f= 8f65aa32/makedefs/MakeInc.def#L578 > > [3]=20 > https://github.com/apple/darwin-xnu/blob/8f02f2a044b9bb1ad951987ef5bab20e= c9486310/libsa/lastkerneldataconst.c#L48 > >> >> Thanks, >> >> Andrew Fish >> >>> Best regards, >>> Marvin >>> >>>> >>>> Thanks, >>>> >>>> Andrew Fish >>>> >>>>> Best regards, >>>>> Marvin >>>>> >>>>>> [1]=20 >>>>>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/Bas= eUefiCpuLib/X64/InitializeFpu.nasm#L14=20 >>>>>> =20 >>>>>> >>>>> >=20 >>>>>> >>>>>> >>>>>> [2] $otool -V -s __TEXT=20 >>>>>> __constBuild/OvmfX64/DEBUG_XCODE5/X64/UefiCpuPkg/Library/BaseUefiCpu= Lib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.obj >>>>>> Build//OvmfX64/DEBUG_XCODE5/X64/UefiCpuPkg/Library/BaseUefiCpuLib/Ba= seUefiCpuLib/OUTPUT/X64/InitializeFpu.obj:=20 >>>>>> >>>>>> Contents of (__TEXT,__const) section >>>>>> 0000001d =C2=A07f 03 80 1f 00 00 >>>>>> >>>>>> $ otool -l=20 >>>>>> Build//OvmfX64/DEBUG_XCODE5/X64/UefiCpuPkg/Library/BaseUefiCpuLib/Ba= seUefiCpuLib/OUTPUT/X64/InitializeFpu.obj >>>>>> Build/OvmfX64/DEBUG_XCODE5/X64/UefiCpuPkg/Library/BaseUefiCpuLib/Bas= eUefiCpuLib/OUTPUT/X64/InitializeFpu.obj:=20 >>>>>> >>>>>> Load command 0 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cmd LC_SEGMENT_64 >>>>>> =C2=A0=C2=A0cmdsize 232 >>>>>> =C2=A0=C2=A0segname >>>>>> =C2=A0=C2=A0=C2=A0vmaddr 0x0000000000000000 >>>>>> =C2=A0=C2=A0=C2=A0vmsize 0x0000000000000026 >>>>>> =C2=A0=C2=A0fileoff 288 >>>>>> =C2=A0filesize 38 >>>>>> =C2=A0=C2=A0maxprot 0x00000007 >>>>>> =C2=A0initprot 0x00000007 >>>>>> =C2=A0=C2=A0=C2=A0nsects 2 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0flags 0x0 >>>>>> Section >>>>>> =C2=A0=C2=A0sectname __text >>>>>> =C2=A0=C2=A0=C2=A0segname __TEXT >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addr 0x0000000000000000 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0size 0x000000000000001d >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0offset 288 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0align 2^0 (1) >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0reloff 328 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0nreloc 2 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0flags 0x80000500 >>>>>> =C2=A0reserved1 0 >>>>>> =C2=A0reserved2 0 >>>>>> Section >>>>>> =C2=A0=C2=A0sectname __const >>>>>> =C2=A0=C2=A0=C2=A0segname __TEXT >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addr 0x000000000000001d >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0size 0x0000000000000006 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0offset 320 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0align 2^0 (1) >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0reloff 0 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0nreloc 0 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0flags 0x00000000 >>>>>> =C2=A0reserved1 0 >>>>>> =C2=A0reserved2 0 >>>>>> Load command 1 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cmd LC_SYMTAB >>>>>> =C2=A0cmdsize 24 >>>>>> =C2=A0=C2=A0symoff 344 >>>>>> =C2=A0=C2=A0=C2=A0nsyms 3 >>>>>> =C2=A0=C2=A0stroff 392 >>>>>> =C2=A0strsize 63 >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Andrew Fish >>>>>> >>>>>> >>>>>>> Thanks for your notes and insight! >>>>>>> >>>>>>> Best regards, >>>>>>> Marvin >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> "For compatibility with other Unix platforms, the following=20 >>>>>>> standard names are also supported: >>>>>>> [...] >>>>>>> .rodata =C2=A0=3D __DATA,__const data >>>>>>> [...] >>>>>>> If the .rodata section contains no relocations, it is instead=20 >>>>>>> put into the __TEXT,__const section unless this section has=20 >>>>>>> already been specified explicitly." >>>>>>> https://www.nasm.us/xdoc/2.13.01/html/nasmdoc7.html=20 >>>>>>> =20 >>>>>>> >>>>>> > >>>>>>> >>>>>>>> [1] otool -lh DxeCore.dll >>>>>>>> ... >>>>>>>> Load command 1 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cmd LC_SEGMENT_64 >>>>>>>> =C2=A0=C2=A0cmdsize 312 >>>>>>>> =C2=A0=C2=A0segname __DATA >>>>>>>> =C2=A0=C2=A0=C2=A0vmaddr 0x000000000002b000 >>>>>>>> =C2=A0=C2=A0=C2=A0vmsize 0x0000000000147000 >>>>>>>> =C2=A0=C2=A0fileoff 180224 >>>>>>>> =C2=A0filesize 8192 >>>>>>>> =C2=A0=C2=A0maxprot 0x00000003 >>>>>>>> =C2=A0initprot 0x00000003 >>>>>>>> =C2=A0=C2=A0=C2=A0nsects 3 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0flags 0x0 >>>>>>>> Section >>>>>>>> =C2=A0=C2=A0sectname __const >>>>>>>> =C2=A0=C2=A0=C2=A0segname __DATA >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addr 0x000000000002b000 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0size 0x0000000000000718 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0offset 180224 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0align 2^4 (16) >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0reloff 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0nreloc 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0flags 0x00000000 >>>>>>>> =C2=A0reserved1 0 >>>>>>>> =C2=A0reserved2 0 >>>>>>>> Section >>>>>>>> =C2=A0=C2=A0sectname __data >>>>>>>> =C2=A0=C2=A0=C2=A0segname __DATA >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addr 0x000000000002b720 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0size 0x00000000000014f0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0offset 182048 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0align 2^4 (16) >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0reloff 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0nreloc 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0flags 0x00000000 >>>>>>>> =C2=A0reserved1 0 >>>>>>>> =C2=A0reserved2 0 >>>>>>>> Section >>>>>>>> =C2=A0=C2=A0sectname __bss >>>>>>>> =C2=A0=C2=A0=C2=A0segname __DATA >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addr 0x000000000002cc10 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0size 0x0000000000144e11 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0offset 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0align 2^4 (16) >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0reloff 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0nreloc 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0flags 0x00000001 >>>>>>>> =C2=A0reserved1 0 >>>>>>>> =C2=A0reserved2 0 >>>>>>>> =E2=80=A6 >>>>>>>> >>>>>>>> [2]=20 >>>>>>>> https://opensource.apple.com/source/cctools/cctools-698/efitools/m= toc.c.auto.html=20 >>>>>>>> =20 >>>>>>>> >>>>>>> >=20 >>>>>>>> >>>>>>>> >>>>>>>> [3] otool more output=E2=80=A6 >>>>>>>> Load command 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cmd LC_SEGMENT_64 >>>>>>>> =C2=A0=C2=A0cmdsize 392 >>>>>>>> =C2=A0=C2=A0segname __TEXT >>>>>>>> =C2=A0=C2=A0=C2=A0vmaddr 0x0000000000000240 >>>>>>>> =C2=A0=C2=A0=C2=A0vmsize 0x00000000000296c0 >>>>>>>> =C2=A0=C2=A0fileoff 1184 >>>>>>>> =C2=A0filesize 169664 >>>>>>>> =C2=A0=C2=A0maxprot 0x00000005 >>>>>>>> =C2=A0initprot 0x00000005 >>>>>>>> =C2=A0=C2=A0=C2=A0nsects 4 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0flags 0x0 >>>>>>>> Section >>>>>>>> =C2=A0=C2=A0sectname __text >>>>>>>> =C2=A0=C2=A0=C2=A0segname __TEXT >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addr 0x0000000000000240 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0size 0x000000000002489f >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0offset 1184 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0align 2^3 (8) >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0reloff 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0nreloc 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0flags 0x80000400 >>>>>>>> =C2=A0reserved1 0 >>>>>>>> =C2=A0reserved2 0 >>>>>>>> Section >>>>>>>> =C2=A0=C2=A0sectname __cstring >>>>>>>> =C2=A0=C2=A0=C2=A0segname __TEXT >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addr 0x0000000000024ae0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0size 0x000000000000496d >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0offset 150848 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0align 2^4 (16) >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0reloff 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0nreloc 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0flags 0x00000002 >>>>>>>> =C2=A0reserved1 0 >>>>>>>> =C2=A0reserved2 0 >>>>>>>> Section >>>>>>>> =C2=A0=C2=A0sectname __ustring >>>>>>>> =C2=A0=C2=A0=C2=A0segname __TEXT >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addr 0x000000000002944e >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0size 0x0000000000000048 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0offset 169646 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0align 2^1 (2) >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0reloff 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0nreloc 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0flags 0x00000000 >>>>>>>> =C2=A0reserved1 0 >>>>>>>> =C2=A0reserved2 0 >>>>>>>> Section >>>>>>>> =C2=A0=C2=A0sectname __const >>>>>>>> =C2=A0=C2=A0=C2=A0segname __TEXT >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0addr 0x00000000000294a0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0size 0x0000000000000448 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0offset 169728 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0align 2^4 (16) >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0reloff 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0nreloc 0 >>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0flags 0x00000000 >>>>>>>> =C2=A0reserved1 0 >>>>>>>> =C2=A0reserved2 0 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Andrew Fish >>>>>>>> >>>>>>>>> >>>>>>>>> =C2=A0=C2=A0DEBUG_XCODE5_IA32_CC_FLAGS =C2=A0=C2=A0=3D -arch i386= -c -g -Os=20 >>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-Wall -Werror -include AutoGe= n.h -funsigned-char=20 >>>>>>>>> -fno-stack-protector -fno-builtin -fshort-wchar -fasm-blocks=20 >>>>>>>>> -mdynamic-no-pic -mno-implicit-float -mms-bitfields=20 >>>>>>>>> -msoft-float -Wno-unused-parameter -Wno-missing-braces=20 >>>>>>>>> -Wno-missing-field-initializers -Wno-tautological-compare=20 >>>>>>>>> -Wno-sign-compare -Wno-varargs=20 >>>>>>>>> -ftrap-function=3Dundefined_behavior_has_been_optimized_away_by_c= lang=20 >>>>>>>>> $(PLATFORM_FLAGS) >>>>>>>>> >>>>>>>>> @@ -3003,7 +3003,7 @@ RELEASE_XCODE5_X64_DLINK_FLAGS =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=3D=20 >>>>>>>>> -arch x86_64 -u _$(IMAGE_ENTRY_POINT) -e _ >>>>>>>>> =C2=A0=C2=A0DEBUG_XCODE5_X64_ASM_FLAGS =C2=A0=3D -arch x86_64 -g >>>>>>>>> >>>>>>>>> =C2=A0=C2=A0NOOPT_XCODE5_X64_ASM_FLAGS =C2=A0=3D -arch x86_64 -g >>>>>>>>> >>>>>>>>> RELEASE_XCODE5_X64_ASM_FLAGS =C2=A0=3D -arch x86_64 >>>>>>>>> >>>>>>>>> - =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*_XCODE5_X64_NASM_FLAGS =3D -f ma= cho64 >>>>>>>>> >>>>>>>>> + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*_XCODE5_X64_NASM_FLAGS =3D -f ma= cho64=20 >>>>>>>>> -DRODATA_SECTION_NAME=3D.rodata >>>>>>>>> >>>>>>>>> *_XCODE5_*_PP_FLAGS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=3D -E -x assembler-with-cpp=20 >>>>>>>>> -include AutoGen.h >>>>>>>>> >>>>>>>>> *_XCODE5_*_VFRPP_FLAGS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=3D -x c -E = -P -DVFRCOMPILE -include=20 >>>>>>>>> $(MODULE_NAME)StrDefs.h >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --=20 >>>>>>>>> 2.31.1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>>=20 >> >