* fix the `-l' gas flag.  (flag_short_refs in md_estimate_size_before_relax()
  in binutils/gas/config/tc-m68k.c)  This would let a few patches in gcc's
  m68k.md and lb1sf68palmos.asm go away; in particular, getting rid of the
  `define_insn "jump"' one would reduce code size, maybe even non-trivially.

* Have some way to ask for a 64K memory region for extra code
  sections -- probably a new option or .def file thing for multigen.

* Don't package the $libdir/ldscripts directory -- it's redundant because
  the scripts are burnt into ld.

* Overhaul the way we accomodate the "%a5 is the *end* of the globals"
  problem in binutils.  Currently we have a weird reloc END16(<foo>,<offset>)
  that means "+ <foo> + <offset> - edata", weird code in bfd to evaluate edata
  (which is hardcoded) at the right time, and weird code in gas to generate
  the reloc.  A possibly feasible alternative is to emit *two* relocs,
  (<foo>,<offset>) and (negedata,0).  The upgrade path is
  * Leave the reloc and bfd code for compatibility with old link libraries
  * Remove the @END stuff in gas since we no longer need to generate it
  * Have GCC emit "<foo>+negedata(%a5)" instead of "<foo>@END(%a5)"
  * Have gas split these fixups into two relocs.  It looks like this is
  flaky in the COFF assembler, but very practical in the ELF assembler.
  There is more research to do here.
* An alternative is to do a trial link to find out how big the global data
  memory region is, and then do the real link with datares ORIGIN = -size.
  This would Just Work, but is less flexible (you can't mix %a4 and %a5
  addressing in the same executable), and I *really* want to avoid doing a
  trial link if possible.

* Update the ChangeLogs, and start submitting patches to the various GNU
  maintainers (without any of the remaining nasty hacks!).

* Consider how to use --emit-relocs instead of --embedded-relocs in ld and
  return to reading real relocs in binres.cpp instead of .reloc sections.

* Perhaps configure GCC with TARGET_MEM_FUNCTIONS so that aggregate
  initialisation is done with memcpy instead of bcopy -- and provide
  memcpy/bcopy more reliably than before.  Or even hack something up so
  that it can use MemMove.

* Future palmdev-prep facilities:
  - Handle multi-libs correctly, instead of just recursively listing
    everything under "lib" directories
  - Add "base" file handling, to facilitate use of SDK updates
  - write_specs with target="none" should mean don't write any link_* specs
  - Perhaps preserve the default SDK when reruning without a -d option,
    instead of resetting to the highest SDK (remember the current setting by
    writing an extra little state file, not by trying to parse a spec file)

* Use @command for commands, @option for options throughout prc-tools.texi.

* Use .PHONY properly in all our makefiles.

* If C++ is not in --enable-languages, we shouldn't try to build C++ target
  support (e.g. new12.cc).  Currently the build fails.

* Find a less hackish way to suppress [un]protoize and gcov.

* Add a post-install script to the Cygwin build to do install-info.

* Issues with the tiny libc implementation:
  - _SP et al in ctype.h
  - strtol/strtoul should be in stdlib.h, not string.h
  - we don't have overloaded const / non-const versions of each function (C++)
  - u_int in sys/types.h

* Proper way to get GCC to search $(datadir)/prc-tools/include is to override
  SYSTEM_HEADER_DIR (or better NATIVE_SYSTEM_HEADER_DIR?) in t-m68kpalmos.
  (See Zack Weinberg's gcc@ message of 2002-08-03 "Re: gcc 3.2's cpp breaks
  configure scripts" <20020803230707.GG466@codesourcery.com>.)

* Implement ARM "-fvery-PIC" that avoids using a GOT, as was done for m68k.
  Currently the compiler will generate GOT-relative relocations in some
  circumstances -- which will crash an armlet, because they don't have the
  infrastructure to set up a GOT.
