Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #670 > unrolled thread

Some problem about the elf file while generating the code for compiler

Back to article view | Back to comp.compilers

Contents

  Some problem about the elf file while generating the code for compiler Jianfei Hu <hujianfei258@gmail.com> - 2012-06-07 01:49 +0800
    Re: Some problem about the elf file while generating the code for compiler Robert A Duff <bobduff@shell01.TheWorld.com> - 2012-06-07 15:55 -0400
      Re: Some problem about the elf file while generating the code for compiler BGB <cr88192@hotmail.com> - 2012-06-09 10:26 -0500

#670 — Some problem about the elf file while generating the code for compiler

Recently I plan to build a simple compiler by myself. When it comes to
elf file generation, I got a problem.  As the elf file specification
says, the segment's virtual addr should be congruent with the offset
in the file modulo page size. Because this would be good for mmap the
elf file into memory efficiently.

But How, why with the same remainder could enhance the efficiency of
mmap file into memory?  As I think, the process would map the segment
into memory twice. In the first time , the segment content would be
put right next to last segment, and then right at the tail of the
first segment content, the second content would be put once more, but
starting at another page. Draw the picture and this is matching the
requirement. Am I right?

And I feel that to implement the simple compiler, I still need some
low level knowledge.  Could someone give me some suggestion or
recommend good resources?
[Yes, an ELF file can map a page twice if it's in two segments.
You might take a look at my Linkers and Loaders book, and at the old
AT&T System V references for details on using ELF. -John]

[toc] | [next] | [standalone]

#678

Jianfei Hu <hujianfei258@gmail.com> 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.

> You might take a look at my Linkers and Loaders book, ...

Good idea in any case -- it's an excellent book.

- Bob

[toc] | [prev] | [next] | [standalone]

#685

On 6/7/2012 2:55 PM, Robert A Duff wrote:
> Jianfei Hu<hujianfei258@gmail.com>  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).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web