From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 14 Feb 1999 15:02:35 +0100 To: David Edelsohn , linuxppc-dev@lists.linuxppc.org From: Benjamin Herrenschmidt Subject: bootstrap stuffs Message-Id: <19990214150235.030449@smtp.calvacom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-linuxppc-dev@lists.linuxppc.org List-Id: On Sat, Feb 13, 1999, David Edelsohn wrote: Thanks for your reply ! > Just to make sure, you are not asking how to create XCOFF >TOC-based code using GCC? Not really, I already have CodeWarrior and MrC for that ;-) > If you know the physical location or can cotrol the physical >location at which the code will be loaded, you simply can instruct the >linker to link the executable based at that location. Otherwise, you >might need additional -fpic position independent code option. If you need >data and cannot set the GPR specifying the GOT address yourself, you can >use the GCC SVR4 eABI PPC suppport to calculate it on entry as it does for >embedded systems. Note that branches generated by GCC already are >position-independent displacements (not "ba" branch absolute instruction). I don't know the physical location. The experiments I did yesterday with various options showed me that the generated branches are bl's except in some case (the linker-generated branches between .o files were sometimes ba, but I probably missed an ld option). So if I understand correctly, I must use -fpic to generate position independant code. I beleive I must also indicate that this is static code (no dynamic link). The GOT is a TOC-like register that's it ? I could probably put a correct value in it if I knew how to find it from the loader. Do you know which options I should use for CFLAGS and LDFLAGS to get the result you mentioned ? (GOT calculated on entry). > Are all of those "sync" instructions necessary in your code? Just paranoid. They were added around the interrupt switching to make sure to sync an eventual second processor and everything else before switching the MMU off. I beleive that for disabling the MMU, andi. is probably more efficient than my ori/andc pair, could you just explain my why you added &0xffff at it ? >You are not touching memory. The instructions already are serializing. I >think that you should be able to do something like: > >enable: > mfmsr r0 > ori r0,r0,MSR_EE > mtmsr r0 > >disable: > mfmsr r0 > andi. r0,r0,(~MSR_EE)&0xffff > mtmsr r0 > -- E-Mail: BenH. Web : [[ This message was sent via the linuxppc-dev mailing list. Replies are ]] [[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]] [[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]] [[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]