From: alexfrunews@gmail.com   
      
   On Monday, February 7, 2022 at 5:44:40 AM UTC-8, James Harris wrote:   
   > 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.   
      
   If you don't have relocations, there isn't any other option.   
   (Position-independent executable wasn't such an option.)   
      
   > 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.   
      
   True. I don't know why they weren't/aren't generated out of the box.   
   Kinda stupid and careless.   
      
   > (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?   
      
   ELF. One object format that's good enough for all 32-bit x86 needs.   
   And for some 16-bit needs too (there are 16-bit relocation extensions   
   in ELF that NASM supports and my compiler/linker depends on).   
   Pretty neat.   
      
   > 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.   
      
   You're somehow overcomplicating the PE format beyond what it really is.   
   If you ignore all those special sections and options and what not   
   and just stick to a few code and data sections and maybe relocations,   
   it's gonna be very simple.   
      
   > >> 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.   
      
   There are two alignment fields in the PE header: section alignment   
   and file alignment. If you set both to 4KB (there should be an option   
   or a way to do it via the linker script), you'll probably just get   
   what you need.   
      
   > 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.   
      
   My guess is you wanted it look like a flat binary, which is missing the point   
   of the format and the format isn't terribly complex for what you really   
   need at this point.   
      
   Get a Windows system (or Wine) and make a few PEs by hand   
   and see them work (or break them and see them not).   
   Here's one example (without relocations; possibly not 100% perfect,   
   but Windows doesn't complain), compilable by NASM,   
   no linker needed:   
   https://github.com/alexfru/SmallerC/blob/master/v0100/smlrcw.asm   
   Btw, it has the sections 4KB aligned within the file.   
      
   Alex   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)