* Now talking in #asm * Topic is '< Phyx-> hmmm my snake has a problem' * Set by forkbomb!kryczek@kryczek.gemnetworks.com on Mon May 22 11:37:31 i have a very off-the-wall question about a linker ... is it appropriate to ask my question here? multiple assembly coff files -> linker -> portable executable type question You might not get an answer, but it's near the topic enough maloeran; to make a long story short, we're working on creating a linker that will take multiple COFF files and output a single portable executable, similar to what microsoft's link.exe does (it's a class project) ... we've already implemented the assembler itself, and we're onto the linker ... everything is making sense, except for combining code sections from multiple coff files into one ... A portable executable? we're noticing 0xCC bytes in between .text sections from multiple coff sections, and the 0xCC bytes don't always come between the .text/.code sections in a consistent order yes, a portable executable x86/win32 PE we're using PEview (a google search has it) to analyze the PE generated by linking multiple COFF files ... Okay, "portable" covers a wider range of archs and/or OSes in my vocabulary :). I wouldn't know the details of linking on windows and the .text section generated for the portable executable ... well, it's not looking like we expect yea the xbox uses PE maloeran; well, could i ask for a general rundown of how multiple .text sections would be linked on a unix or linux or another platform for that matter? maybe that would help? maloeran; aside from procedure/function calling conventions ... the .text sections are combined a certain way, right? maloeran; i'd be happy to share the 3-4 files we're looking at, if you'd like to see them The certain way isn't that much relevant, as long as the addresses to other sections to merge are set correctly maloeran; well, considering we're seeing these 0xCC opcode fillers between .text sections, is there a particular document i can google for in order to determine what these 0xCC bytes represent? How many of these bytes do you have? Could it be mere padding to conserve alignment? well, the x86/CISC instructions are variable-length though, right? Right we usally have one CC byte between sections, but there's some cases when we have more than one ... and we can't determine, reliably, what those cases are that generate more than one CC byte (and why) ...