X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10605110108.AA17525@clio.rice.edu>
Subject: DJGPP ELF (fwd)
To: djgpp-workers AT delorie DOT com (DJGPP developers)
Date: Wed, 10 May 2006 20:08:05 -0500 (CDT)
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavis-2.2.1 at scan1.mail.rice.edu
Reply-To: djgpp-workers AT delorie DOT com

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