Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!nerds-end From: BGB Newsgroups: comp.compilers Subject: Re: Some problem about the elf file while generating the code for compiler Date: Sat, 09 Jun 2012 10:26:35 -0500 Organization: albasani.net Lines: 51 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <12-06-024@comp.compilers> References: <12-06-009@comp.compilers> <12-06-017@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: leila.iecc.com 1339394874 48721 64.57.183.58 (11 Jun 2012 06:07:54 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Mon, 11 Jun 2012 06:07:54 +0000 (UTC) Keywords: assembler, design Posted-Date: 11 Jun 2012 02:07:54 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:685 On 6/7/2012 2:55 PM, Robert A Duff wrote: > Jianfei Hu writes: > >> Recently I plan to build a simple compiler by myself. When it comes to >> elf file generation, I got a problem. > > You might want to side-step that problem by having your compiler > generate assembly language as text. And then feed that to an > assembler. If your purpose is to learn about compilers, then this > allows you to learn the interesting and important stuff, while > avoiding learning boring nitty-gritty details, such as the one you > mentioned. IMHO, having an assembler in the mix is a good idea regardless of whether or not it is provided by the system, or is simply some library code. this way, there is a good abstraction point: compiler produces ASM; compiler passes said ASM to the assembler. other code can be written to pass code to the assembler, and it also makes it easier to dump the ASM output to files to allow for easier inspection of compiler output. IME, it doesn't seem to necessarily add all that much to the compile times either, but may depend some on the specifics of the assembler (for example, my assembler is considerably faster if using single-pass assembly and macros are disabled, ...). but, then again, the assembler also uses things like hash-chains to lookup opcode mnemonics and similar as well. potentially, faster is possible by directly crafting machine code in a compiler, but is this really worthwhile? I have doubts. an assembler may deal with a lot of the binary encoding issues once, and is then done with it. for direct output, this may need to be dealt with for each and every construct. >> You might take a look at my Linkers and Loaders book, ... > > Good idea in any case -- it's an excellent book. possibly an idea, albeit admittedly I haven't actually read it. for the original question, my thought here is that it may make sense to keep the virtual addresses and file-offsets mapped 1:1, as IMO this makes some things nicer in general (but can waste a little bit of space if combined with keeping all sections page-aligned).