FreeBSD. This method attempts to centralize all the necessary hacks
or work arounds in one of two places in the tree (src/Makefile.inc1
and src/tools/build). We build a small compatibility library
(libbuild.a) as well as selectively installing necessary include
files. We then include this directory when building host binaries.
This removes all the past release compatibilty hacks from various
places in the tree. We still build on tip of stable and current. I
will work with those that want to support more, although I anticipate
it will just work.
Many thanks to ru@, obrien@ and jhb@ for providing valuable input at
various stage of implementation, as well as for working together to
positively effect a change for the better.
or dead kernel core is loaded into gdb. This extends gdb's existing
shared library support, so the "info sharedlibrary", "sharedlibrary"
and "nosharedlibrary" commands can be used to view and change the
list of loaded symbol files.
The current implementation is more than a kludge however, and it
will not always manage to find the .ko.debug file corresponding to
the loaded module. In particular, for modules whose build directory
cannot be easily guessed from the module name such as all the
netgraph modules, the debug version of the .ko will not be found
automatically.
The logic for finding the module file first attempts to guess at
the module build directory by parsing the version[] string. Then
using that directory ($DIR), it tries the following paths in turn:
./<module>.ko.debug ./<module>.ko
$DIR/<module>.ko.debug $DIR/<module>.ko
/boot/kernel/<module>.ko.debug /boot/kernel/<module>.ko
Approved by: obrien, mp
contrib/binutils/include/getopt.h
/* Many other libraries have conflicting prototypes for getopt, with
differences in the consts, in stdlib.h. To avoid compilation
errors, only prototype getopt for the GNU C library. */
so manually define HAVE_DECL_GETOPT since configure doesn't offer any way
to set it... and its unistd.h not stdlib.h dang it.
than piping thru tr(1). Also prefer case over for+test, as case will
handle regex's nicely.
Note we can't exactly follow the real 2.13 genscripts.sh as we wind up with
multiple "'s in search paths. It is too late tonight to track down why.
under way to move the remnants of the a.out toolchain to ports. As the
comment in src/Makefile said, this stuff is deprecated and one should not
expect this to remain beyond 4.0-REL. It has already lasted WAY beyond
that.
Notable exceptions:
gcc - I have not touched the a.out generation stuff there.
ldd/ldconfig - still have some code to interface with a.out rtld.
old as/ld/etc - I have not removed these yet, pending their move to ports.
some includes - necessary for ldd/ldconfig for now.
Tested on: i386 (extensively), alpha
non-i386 platforms.
I would however like to see a shared file here. If a function or two cannot
be shared we should create ${TARGET_ARCH}/kvm-fbsd-${TARGET_ARCH}.c.
xmalloc() and xrealloc() and the mixed usage of xmalloc in some .c's from
libiberty.a and other .c's from libreadline.so produces an unusable binary
on the Alpha.
While I am here, preventatively move other libs in the link order.
Submitted by: gallatin
Correct backtrace was made more complex when the new signal trampoline
was introduced to support more than 32 signals, while keeping a modified
version of the old signal trampoline.
The 'where' command will now show:
#2 <signal handler called>
where appropiate.
Submitted by: Tor.Egge@fast.no
Rev 1.2 changed the default emulation from ``elf64_sparc'' to ``elf32_sparc''
and I never noticed it after my review of rev 1.1. Backing the change of
the default emulation out, and Wa-la!, I can now build a native [and usable]
binutils. WTF, the "-m elf64_sparc" parameter handed to `ld' by `gcc'
wasn't DTRT is beyond me.
Presumably the issue was with arparse.[ch]. Those are now in FREEBSD-Xlist
and FREEBSD-deletelist. So we do not import the Bison produced files that
was causing the problem.
Submitted by: ru
(the two may be different (ie, build vs. runtime))
Allow ldscript's SEARCH_DIR do be rooted somewhere other than `/'.
(in this case at TOOLS_PREFIX)
These changes are most helpful during `make buildworld' so that the shared
libs built in the middle of `make buildworld' are used vs. the ones in
/usr/lib on the build machine.
Submitted by: ru
code in ipl.s and icu_ipl.s that used them was removed when the
interrupt thread system was committed. Debuggers also knew about
Xresume* because these labels hide the real names of the interrupt
handlers (Xintr*), and debuggers need to special-case interrupt
handlers to get the interrupt frame.
Both gdb and ddb will now use the Xintr* and Xfastintr* symbols to
detect interrupt frames. Fast interrupt frames were never identified
correctly before, so this fixes the problem of the running stack
frame getting lost in a ddb or gdb trace generated from a fast
interrupt - e.g. when debugging a simple infinite loop in the kernel
using a serial console, the frame containing the loop would never
appear in a gdb or ddb trace.
Reviewed by: jhb, bde
are linking against does not have basename(). There is a buffer overflow
bug in lib/libc/gen/basename.c rev 1.1. There is no way for us to test
what revision of basename() we have in libc, thus this change.
Requested by: ru
misuse of /usr/src/include headers. This REALLY fixes
the 20010919 src/UPDATING entry.
With this patch the 4.2-RELEASE box was able to survive
the 5.0-CURRENT "make world".
Beat over the head with this patch: obrien
The version of the kernel has no bearing on what is in libc.
We now search for basename in libc to determin if we need to include
the libiberty version in the build.
This is all still a bit bogus as it will (like the sysctl method) cause
basename.o to be linked into the cross-build as well as the host build. It
would probably be better to test if we were doing the initial host build and
unconditionally include that. Once we've generated the target libc we know
that basename is available. (maybe test for $TOOLS_PREFIX or something).
Submitted by: peter
Note ALL MODULES MUST BE RECOMPILED
make the kernel aware that there are smaller units of scheduling than the
process. (but only allow one thread per process at this time).
This is functionally equivalent to teh previousl -current except
that there is a thread associated with each process.
Sorry john! (your next MFC will be a doosie!)
Reviewed by: peter@freebsd.org, dillon@freebsd.org
X-MFC after: ha ha ha ha
reading old a.out core files, which are totally 100% non-understandable
to the gdb floating-point reader if you have SSE turned on.
This should be the last of the world build breakers...
end of the include searching. We really need a real fix for the issue of
which set of headers to use in compiling the cross-tools -- /usr/include,
or /usr/src/include.
call and trap entry points so they're easy to find and change
- Use the cpuhead and allcpu list to locate globaldata for the current
cpu, rather than SMP_prvspace or __globaldata
- Use offsets into struct globaldata directly to find per-cpu variables,
rather than symbols in globals.o
Glanced at by: peter
when using gdb on a remote target. The fix is to restrict PT_GETDBREGS
calls to `child' and `freebsd-uthreads' targets solely.
I've been in some conversation with Brian about this, and this solution
seems to be the most appropriate one.
PR: gnu/21685
Submitted by: bsd
`wait.h' that was in contrib/binutils/, however this wait.h went away with
bintuils 2.10.0 so I `cvs rm'ed it. Now we find gdb will not build. This
binutils wait.h contained nothing we didn't already have in <sys/wait.h>.
So just hack a symlink to it.
with Brian's kernel support for i386 debug registers. This makes
watchpoints actually usable for real-life problems. Note: you can
only set watchpoints on 1-, 2- or 4-byte locations, gdb automatically
falls back to [sloooow] software watchpoints when attempting to use
them on variables which don't fit into this category. To circumvent
this, one can use the following hack:
watch *(int *)0x<some address>
David O'Brien is IMHO considering to get this fully integrated into the
official GDB, but as long as we've got the i386/* files sitting around
in our private FreeBSD tree here, the feature can now be tested more
extensively, so i'm committing this for the time being.
This work has been done in order to debug a tix toolkit problem, thus
it has been sponsored by teh Deutsche Post AG.
Reviewed by: bsd (not the operating system, but Brian :-)
libraries in LDADD so that `make checkdpadd' doesn't report non-errors.
Fixed some style bugs (the usual ones for DPADD and LDADD, and misformatting
of $FreeBSD$).
The target machine is represented by TARGET_ARCH. MACHINE_ARCH always
represents the host machine. When TARGET_ARCH is not defined, it is
assumed to be equal to MACHINE_ARCH. This means that we're building a
native toolset by default. We're creating cross-compilation tools when
MACHINE_ARCH != TARGET_ARCH.
TARGET_ARCH is defined when building binutils as part of the bootstrap
build and is set to reflect the architecture we're currently cross-
building. With this change binutils is ready for cross-building.
All Makefiles now use MACHINE_ARCH for the target architecture.
Unification is required for cross-building.
Tags added to:
sys/boot/Makefile
sys/boot/arc/loader/Makefile
sys/kern/Makefile
usr.bin/cpp/Makefile
usr.bin/gcore/Makefile
usr.bin/truss/Makefile
usr.bin/gcore/Makefile:
fixed typo: MACHINDE -> MACHINE_ARCH
tidy up the logic that works out which sub-directories to build.
The new directories with freebsdelf suffixes now have freebsd suffixes
after a repo move by Peter at the request of David O'Brien.
directory to /usr/cross/${MACHINE_ARCH}-freebsdelf/usr/lib so that
the cross tools behave the same way that the host versions do. When
building cross tools, Cygnus doesn't set the default library directory.
This doesn't suit FreeBSD IMHO.
Add WinNT emulation support too. You only get this if you've set
BINUTILSDISTDIR because the contrib/binutils repository doesn't
contain the required sources.
directory to /usr/cross/${MACHINE_ARCH}-freebsdelf/usr/lib so that
the cross tools behave the same way that the host versions do. When
building cross tools, Cygnus doesn't set the default library directory.
This doesn't suit FreeBSD IMHO.
gas for i386 targeted to NT for those (like me) who have to do work
targeted to NT, but can't stand actually looking at it all day long.
I cross build apps on FreeBSD and just run them on NT later. Life is
better that way.
Allow for the case where the host architecture might also be listed
in CROSS_ARCH, so don't do things twice. This situation can arise if you
want NT support in binutils (CROSS_ARCH=i386 CROSS_FORMAT=winnt).
* Update build for gdbserver and gdbreplay to work under binutils
* Fix gdbserver to use PT_GETREGS etc to access registers, removing the
dependancy on the u-area.
* Make gdbserver work on the alpha.
zero when building for little endian machines.
Correct the target names for mips. We just use the generic targets
for mips elf, so the mipse[lb]-unknown-freebsd emulation types don't
exist.
name of the bfd target, not the gnu-standard target name. Corrected
to be elf32-{big,little}mips from mipse[bl]-unknown-freebsd.
DEFAULT_EMULATION was bogusly defined, causing ld to always fail (this
was masked by the TARGET bogosity). Define correctly as elf32bmip and
elf32lmip. Mips doesn't follow the same conventions as i386 and alpha
do in this area.
ld now appears to work correctly for the uncommitted mips changes to
egcs.
Unlike the unisex architecutres we've had so far, mips is bisexual.
These tools can produce either byte sex, and the compiler/make
determines the proper gender to use. Otherwise, we'd have to have had
mipsel and mipseb in all the places that we have just mips. And there
are other complications with doing that (binutils doesn't like to
build mips tools without both byte genders, it seems).
Introduced BINUTIL_ARCH so that other bisexual architectures can a
generic mechanism.
We cannot just define MACHINE_ARCH as mips because we need to
differentiate big and little endian types of binaries. Discussions on
freebsd-arch have hashed out this issue (and the parallel libc
issues). NetBSD is moving towards mipsel and mipseb for their two
flavors of mips ports (in time for 1.4, if this change hasn't already
been accomplished).
I've been building i386 worlds with this tree for a three months with
these files in place with no ill effects.
