From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <430070383b94972b041c1bccc7bcb5d9@caldo.demon.co.uk> To: 9fans@cse.psu.edu Subject: Re: [9fans] gcc trouble From: Charles Forsyth In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Sat, 8 Nov 2003 08:24:43 +0000 Topicbox-Message-UUID: 82e95c3a-eacc-11e9-9e20-41e7f4b1d025 >>I think the right place to catch it is at the back of gnuld. Build a bfd >>module that does plan 9 object format, and use the -o switch to ld to get >>that format. the plan 9 object files (if you mean .8 etc) are binary, but not binary object code. they contain instructions in a symbolic form. only the loader knows the machine encoding, and it does final machine instruction selection. gnu ld looks fairly conventional: the linker doesn't really know much about the machine instructions, but applies some relocation functions on command of the assembler or compiler in a fairly mechanical if complex way. you'd therefore need to disassemble the code inside gnu ld to produce .8 files. mind you, given the size of bfd--it takes 161,177 lines in 92 files to handle all the different elf variants in the copy i've got--it would hardly be noticed. elflink.h alone is 6332 lines (but elf-like it cunningly contains reams of static functions). put one elf that size in Lord of the Rings and even Sauron would have been given pause for thought. they'd also have had to send out for bigger film.