[qcc] Fwd: Re: qcc

[Rob Landley]

On 02/18/2015 08:29 AM, Bruce Ewing wrote:
> Hi,
> 
> I've been writing my own OS for 7 or 8 years now and I'm about to start
> "self-hosting" it.
> One of the things this means is that I'm looking to migrate off gcc to
> something BSD-licensed, if possible.
> 
> My OS is written in a subset of C, so something like otccn is a
> possibility (but not BSD).
> Another possibility is NWCC. A third possibility would be your Qcc -- it
> sounds like an interesting project, but it appears to be a bit stalled. ;)

Because I'm focusing on getting toybox to 1.0 first, yes. My reasons why
are explained in:

  http://landley.net/aboriginal/about.html#selfhost

There's also a video of a talk I gave about it at ELC 2013:

  video: http://youtu.be/SGmtP5Lg_t0
  outline: http://landley.net/talks/celf-2013.txt

> My OS uses musl as the basis of the runtime C library, so I am fairly
> familiar with that code.
> 
> So I'm wondering if you would like a little help with the project? Maybe
> I could do enough over the next few months to get you to a rev 0.0.1 at
> least.
> 
> Sincerely,
> 
> Bruce Ewing

I would be enormously interested in help, yes.

My first big todo item is following up on Fabrice Bellard's permission
to use his code under a BSD license. I tracked down the complete list of
external contributions to his original codebase from before mine forked off:

  http://landley.net/notes-2012.html#14-06-2012

Those numbers are the hg commit numbers in my repo, ala "223" would be
http://landley.net/hg/qcc/rev/223

I need to go through those and either remove them or contact the
original contributor and get permission to relicense his code. I'd
prefer to use the Toybox license if Fabrice would accept that as
BSD-like enough:

  Copyright (C) 2006 by Rob Landley <rob at landley.net>

  Permission to use, copy, modify, and/or distribute this software
  for any purpose with or without fee is hereby granted.

  THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
  WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
  WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
  AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
  DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
  PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
  TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  PERFORMANCE OF THIS SOFTWARE.

Once the license issues are cleared up, the next step is making sure
what's there builds on a current distro, and rebuilds itself afterwards
using the host's libc. (It still builds under aboriginal linux against
uClibc, but ubuntu 12.04 had some hiccup with linking or something? I
forget.)

After that, I'd like to refactor it into a multicall binary, ala busybox
and toybox. Break out the preprocessor code and the linker code into
separate files, and have the main() funciton figure out if it's called
as "ld" or "cpp" or "as" or "strip" and behave appropriately each time.

I note that I rewrote my ccwrap.c from scratch, which parses a gcc-style
command line and rewrites it to start with -nostdinc -nostdlib and then
explicitly adds all the header and library includes (and crt1.o and so
on) so the build is properly relocatable without requiring gcc to use
_any_ of its built-in path logic (which is too broken to live). I'd like
to merge this code into qcc to form the basis of a gcc-compatible
command line option parser.

In terms of the infrastructure:

1) I was halfway through a port to 64 bits. I see a contributor to the
other tinycc completed said port, with an x86-64 backend target. That
would need to be redone.

2) Basic dead code elimination is necessary for building things like
busybox and toybox and the kernel. We've already got constant
propagation, so if (0) shouldn't be too hard to detect. There's a corner
case where goto labels can reactivate code that was previously dead
(jumping back up into a block that otherwise couldn't be reached), but
you can see the label at declaration time, so if our "dead code" is
generated to a temporary buffer it can be reactivated if we encounter a
(non-switch/case) label (output the buffer out instead of discarding
it), and then figuring out if the label is _used_ can be additional
optimization later. I think the simple case lets us build the basic
packages...

3) We need nm --size-sort and an objdump -d because the kernel uses that
stuff during the build. Right now toybox doesn't provide it. (Writing a
disassembler isn't a huge deal but needs to be repeated for each target,
just like the assembler. Speaking of which, I don't remember if our
assembler handles standalone .S files yet, the kernel has plenty of them.)

All of that is preparatory cleanup to the big merge with qemu's tcg.

Rob