From: james.harris.1@gmail.com   
      
   On 10/01/2022 05:42, Alexei A. Frounze wrote:   
   > On Saturday, January 8, 2022 at 4:26:08 AM UTC-8, James Harris wrote:   
   >> On 07/01/2022 02:44, Alexei A. Frounze wrote:   
   >>> On Wednesday, January 5, 2022 at 8:39:10 AM UTC-8, James Harris wrote:   
   >>>> I should say I remember someone (Alex?) since long ago espousing a   
   >>>> certain .exe format as being very easy to relocate but I am not sure   
   >>>> whether it was suitable for 32-bit code,   
   >>>   
   >>> The 32-bit PE image is easy to relocate (the 64-bit PE should be easy too),   
   >>> there's only one x86-32 kind of relocation: IMAGE_REL_BASED_HIGHLOW   
   >>> (=3) in the .reloc section. That is, if the base address differs from the   
   >>> one in the image header, you add a constant to all locations enumerated in   
   >>> the .reloc section.   
   >> A relocatable PE may be easy to relocate ... but it doesn't seem so easy   
   >> to create. :-(   
   >   
   > Not easy because you don't have the right tools or because you haven't   
   > yet worked out the formats on both sides (input obj and output exe)?   
      
   It was "not easy" probably because of incompatibility between how things   
   work and my expectations of how they 'should' work.   
      
   For example, I was surprised (and still am) that a load module would be   
   compiled to run in just one fixed location and never any other. I could   
   understand a preferred location but not a fixed one.   
      
   Is there a particular advantage in stripping off the relocations? The   
   change in file size will surely be tiny and I cannot see any security   
   advantages to removing the relocs. Just the opposite, in fact.   
      
   (It's no longer a problem, BTW. I've worked round it. My comment about   
   stripped relocs is purely philosophical.)   
      
   >   
   > I simply wrote my own linker to be able to produce the different kinds   
   > of executables I wanted. And it works great in the relatively simple   
   > scenarios I have (statically linked executables for the most part;   
   > Windows ones are an exception since the Windows API isn't defined   
   > as some kind of int#/fxn# in DOS or Linux and must be imported   
   > from system libraries).   
      
   OK, though what is the format of the object inputs to your linker?   
      
   ISTM that whenever we have to work with systems or formats someone else   
   has designed we end up having to deal with lots of complexity.   
      
   >   
   >> Those I make seem to come without any relocation entries.   
   >   
   > Might be that you aren't asking the linker to produce them for you.   
   > That's what MinGW does by default. There are two tweaks here:   
      
   ...   
      
   Thanks for the info (now snipped). You have worked out how to wrangle   
   the tools into submission - which is what I felt like I was trying to do.   
      
   I spent some time looking at PE and then at a.out for booting but I   
   ended up getting my compiler to emit PIC so I can boot via a flat   
   binary. I expect later to have to use PE - not least because of its   
   association with UEFI - but it will be easier for me to load PE using   
   HLL code rather than assembly (which is what I need at boot time).   
      
   As I looked in to it I was becoming increasingly uncertain that PE could   
   be made to do what I wanted. For example, for my environment the linker   
   expects sections to be loaded into memory at 4k alignment but they have   
   smaller alignment in the file. I needed the executable to run from   
   wherever the file happened to be loaded. It /may/ have been relocatable   
   as it stood but I couldn't be sure and thought maybe I was trying to get   
   the format to do something it was not designed for.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)