Mail Archives: djgpp-workers/2006/05/10/21:29:55
Forwarded message:
> Date: Wed, 10 May 2006 11:45:56 -0700 (PDT)
> From: Daniel Borca <dborca AT yahoo DOT com>
> Subject: DJGPP ELF
>
> Hi Charles,
>
> I tried to reach you a while ago (about DJGPP ELF)
> to no avail. However, I just wanted to let you know
> that I've uploaded the latest version on my page:
> http://www.geocities.com/dborca/djgpp/elf/djelf.html
>
> As usual, this release does not affect default COFF
> system, it only adds functionality for ELF.
>
> The binaries are on another geocities page, so you may
> experience geocities' bandwidth limit.
>
> This version features:
> djdev204-elf with libm and libc, C compiler, libgcc,
> C++ compiler and libraries. All libraries are provided
> as shared and static. A small testbed is provided
> for both C and C++ (including exception support).
>
> I also have an alternative to traditional ELF programs.
> It is based on position independent executables (PIE).
> This code has smaller footprint (memory, crt0 code and
> stub), has a more standard interface (supported by the
> modern binutils toolchain) and is generally more suited
> to a DOS environment without fixed memory mapping.
> As a bonus, there are 99.99% chances that we would never
> have to free memory in MULTIBLOCK during crt0 code.
>
> I am tempted to base the next DJELF release completely
> on PIE.
>
> --- Charles Sandmann <sandmann AT clio DOT rice DOT edu> wrote:
>
> >
> > > BUT, I just had this lingering idea on the back
> > > of my head... I changed the GCC sources to have
> > > the Assembler backend (cc1) emit the
> > > ".type, $function", ".type, $object", ".size",
> > > and cut the underscores. Then, I added ELF emulation
> > > to the binutils (while keeping i386go32 as main
> > > target). Much to my surprise, it worked. Finally, I
> > > added a new target to my own DOS extender: a crude
> > > ELF loader, without any relocation (the extender-less
> > > loader is very small, a few hundred bytes).
> > >
> > > Here comes the best part: the crt* code is able
> > > to relocate the main image (including itself),
> > > and also load/relocate any needed SOs (LIBC.SO,
> > > LIBGCC.SO, whatever). The loader proper is written
> > > in C (some code snarfed from v2tk/brstn008.zip).
> > > And yes, it works. The crt* code uses its own
> > > crippled routines for filehandling and does not rely
> > > on any LIBC stuff. crt* is about 6.5kb, but it may
> > > grow up to 10k when finished: LD_LIBRARY_PATH
> > > searching, proper LFN and so on...
> > >
> > > [skipping here the grossy details about how to
> > > access data without knowing whether it is relocated,
> > > and how some pieces of code must run both in
> > > relocated and unrelocated mode]
> >
> > All quite interesting, actually ...
> >
> > > I ported a small portion of LIBC to ELF, but I'm
> > > far from finished. Since "cc1" is the only piece
> > > that's not really compatible with DJGPP, I'm
> > > using the following sequence for compiling a C
> > > program:
> > > gcc -o %.i -E -P %.c
> > > cc1 -o %.s %.i
> > > as -o %.o --emulation elf_i386 %.s
> > > ld -m elf_i386 ...
> > > The sample test programs run well on Win9x/Win2k/XP.
> > >
> > > PS: perhaps no one is really interested in switching
> > > DJGPP to ELF anymore, but I'm doing it as a hobby. ;)
> >
> > If you contributed the pieces, you would get migration
> > eventually. It is just such a big piece of work...
> >
> > > PPS: the MULTIBLOCK approach is not well-suited for
> > > freeing memory via `sbrk()'.
> >
> > A known issue; with Multiblock you pretty much assume
> > memory is never reduced. so DXEs loaded into sbrk()ed
> > memory would not be releasible, but that wouldn't be
> > an issue for the libc...
>
> Regards,
> Daniel Borca
- Raw text -