the binutils headers for (machine)-unknown-freebsdelf.
Also copy the bfd.h header to an architecture specific directory
because there are two fundamental lines that differ (32-bit vs 64-bit)
between i386 and alpha.
The config.h for libbinutils generates the same on alpha as i386,
so I didn't change that (though I was tempted!).
support building it for variant architectures. It was already
becoming clear that the former structure was too rigid and didn't
scale well.
The usual sort of makefile magic arranges to .include an architecture
specific makefile "Makefile.${MACHINE_ARCH}" in each directory
where it exists. Also, sources will be found in each subdirectory
"${MACHINE_ARCH}" that exists. This is all taken care of automatically
by the top level "Makefile.inc0".
This all seems to work right for the i386 now. I have also converted
those alpha pieces already present to the new schema as best I
could.
Also: change the BINDIR on the i386 to /usr/libexec/elf for "ar"
and "ranlib". They are not object format independent enough to
put into /usr/bin.
a.out gas and the binutils gas (elf or a.out) with a single compiler.
This uses other infrastructure not yet committed, in order to support
both a.out and elf it needs to be able to get to both a.out and elf
gas, ld, libs, crt* etc. So for now, the support is pretty much dormant.
The new freebsd.h file is based on the old freebsd-elf.h file (which has a
long lineage, right back through linux and svr4 files). The change is
pretty dramatic from a gcc internals standpoint as it overrides a lot of
definitions in order to generate different output based on target mode.
There is potential for screw-ups, so please be on the lookout - gcc's
configuration mechanism wasn't really meant for this kind of thing.
It's believed to compile world etc just fine under both a.out and elf, can
handle global constructors and destructors, handles the differences in
a.out and elf stabs, and what sections things like exceptions go in.
The initial idea came from i386/osfrose.h which is a dual rose/elf format
target. These two are not as diverse as a.out and elf it would seem.
The cc front-end uses external configuration to determine default object
format (still being thrashed out, so read the source if you want to see
it so far), and has a '-aout' and '-elf' override command line switch.
There are some other internal switches that can be accessed, namely -maout,
-mno-aout, -munderscores and -mnounderscores. The underscore and local
symbol prefixing rules are controllable seperately to the output format.
(ie: it's possible to generate a.out without the _ prefixes on symbols and
also to generate elf with the _ prefixes. This isn't quite optimal, but
does seem to work pretty well, except the linkers don't always recognise
the local symbols without their normal names)
The default format is a.out (still), nobody should see any major changes.
With both elf and a.out tools and libraries installed:
[1:26pm]/tmp-223> cc -elf -o hello hello.c
peter@beast[1:27pm]/tmp-224> file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped
[1:27pm]/tmp-225> ./hello
hello world!
[1:27pm]/tmp-226> cc -aout -o hello hello.c
[1:27pm]/tmp-227> file hello
hello: FreeBSD/i386 compact demand paged dynamically linked executable not stripped
1:27pm]/tmp-228> ./hello
hello world!
Since my co-conspirators put a lot of effort into this too, I'll add them
so they can share the blame^H^H^H^H^Hglory. :-)
Reviewed by: sos, jdp
libraries so that `ld -f' in can create correct dependencies for
yet-to-be-built libraries.
Get the default BINDIR correctly (by including ../Makefile.inc recursively.
objects depend on all generated headers doesn't work because it gives
cyclic dependencies. Give enough dependencies explicitly. We no
longer need to use .SINGLESHELL for `make depend'. .SINGLESHELL was
more of a bottleneck than usual because `make depend' makes everything.
Fixed some spelling and English errors.
${SRCS} instead of giving inadequate explicit dependencies. There
is still a problem after `make depend; make clean'. Then `make'
barely works, and `make -jN' is confused by absolute paths in
.depend.
strip program (via "install") to strip itself. But the program
wasn't executable because "install" hadn't made it so yet. I
borrowed the method used for the old strip to get around this.
This finishes up the binutils import. But I am leaving it disabled
in "src/gnu/usr.bin/Makefile" for now. It is not used by anything
yet, so I'll take this opportunity to run one more round of tests
before enabling it.
*replace* the SUBDIR list in that case, you want to augment it.
Also move a stray .endif to its proper location. Heh, no wonder my
release builds were falling over! ;)
0xefbfe000) and kernel_start (normally 0xf0100000).
Things are unnecessarily (?) difficult because procfs is used to
access user addresses in the live-kernel case although we must have
access to /dev/mem to work at all, and whatever works for the
dead-kernel case should work in all cases (modulo volatility of
live kernel variables). We used the wrong range [0, kernel_start)
for user addresses. Procfs should only work up to VM_MAXUSER_ADDRESS,
but it bogusly works for reads up to the address 2 pages higher
(the user area, including the kernel stack, is mapped to where the
user area used to be (WTUAUTB)). Procfs can not work at all for
addresses between WTUAUTB and kernel_start.
Now we use procfs only to access addresses up to VM_MAXUSER_ADDRESS.
Higher addresses are translated normally using kvtophys(), so the
user ptd is used for addresses below the real kernel start (0xf0000000;
see INKERNEL()) and nothing is found WTUAUTB.
Strange accesses that cross the user-kernel boundary are now handled,
but such ranges are currently always errors because they necessarily
overlap the hole WTUAUTB.
Short reads are still not handled.
Correct translations would have been null. However, kstack was
the top of the kernel stack instead of the base of the kernel stack
like it was when the kernel exported it, so the area above the
kernel stack was mistranslated and the kernel stack was not
translated. This bug was depended on to compensate for the wrong
value of kstack - to read the pcb, instead of just using the address
of the pcb, we used the mistranslated address of kstack, which
happened to be the same (curpcb = kstack - 0x2000).
This area is simpler than it used to be now that the kernel stack
address is per-process. The code still seems to be more complicated
than necessary - the `found_pcb == 0' case seems to be unused.
gdb was cloned from the buggy version of kvm_uread() in libkvm and
had the same bugs. It looped endlessly on EOF and checked errno
without setting it in the lseek() error check. The first bug caused
gdb to loop endlessly for reads from addresses between the end of
the user area and the start of the kernel text. kvm_uread() should
not be used for addresses beyond the end of the user area, but is
due to bugs elsewhere.
the previous frame is in the usual place even for traps, interrupts
and syscalls in the kernel, because the assembly language stubs
don't change the frame pointer. The previous frame is just not for
the calling function. We may as well depend on this as on magic to
determine the trap frame address. The magic is in FRAME_SAVED_PC()
which elides the correct number of stubs (1) to go back to a pc that
matches the previous frame.
Removing fbsd_kern_frame_chain() fixes bugs in it. Xsyscall was
misspelled as _Xsyscall (gdb removes one leading underscore), so
the tf_syscall frame type was never found. This was harmless
because tf_normal works in all cases in fbsd_kern_frame_chain()
and Xsyscall is spelled correctly in fbsd_kern_frame_saved_pc()
where it matters. There were style bugs on almost every line,
starting with a primary indent of 7.
machine independent, with the only dependency being the binary format
to build. We only expect to build ELF on alpha although we'll need
ECOFF compatibility with Digital Unix.
reduces to a relocatable symbol plus an offset. This preserves
the symbol type information (function vs. object). It is important
for SVR4-style weak symbols, e.g., "#pragma weak foo=bar". Without
this change, the linker complains that the jmpslot entry is not a
function.
Submitted by: Robert Eckardt <roberte@MEP.Ruhr-Uni-Bochum.de>
Sundry man page fixes; handle Central European Summer Time (CEST);
usage fixes in line with man page fixes.
It maybe right, if patch was FreeBSD-own program, but it break compatibility
with pre-existent patches in other systems.
The example is big ncurses patch which don't apply on FreeBSD
due to "fixed" precedence.
confused when they can't find it), but leave the reference to it
as being a standard filename (which doesn't imply that it exists).
Discussed with: jkh
Enabled this new feature with the makefile variable GREP_LIBZ. If
you don't like it, compile with `make GREP_LIBZ='.
grep + zlib has several advantages:
- the shell script zgrep(1) will be basically a one line
exec grep -Z "$@"
- no shell script, no bugs. The current zgrep implementations
have many bugs and some grep options are no supported.
- no shell script, no security risks.
- it is a magnitude faster than a shell script
Also fixed:
0 -> STDIN_FILENO
Close a file descriptor only if the open call was successfully. It does
not hurt for the open(2) function, but the gzclose(3) function
died in free() to free up (not) allocated memory.
following "panic:" or "Fatal trap". `panicstr' is still printed,
although it is redundant if there is a valid message buffer and
incomplete if it contains `%'s. I think the awk command belongs
here and not in a script since a standard format with complete
messages is good for bug reports.
emacs a.out file, self-generated by emacs's "unexec" function in
"unexsunos4.c", is invalid. In particular, its "_end" symbol has
the wrong value. The dynamic linker was using the value of that
symbol to initialize its sbrk break level.
The workaround is to peek at the executable's a.out header in
memory, and calculate what "_end" should be based on the segment
sizes.
I will work out a fix for emacs and send it to the FSF. This
dynamic linker workaround is still worthwhile, if only to avoid
forcing all emacs users to build a new version.
Note: xemacs gives a bogus warning at startup, for related reasons.
The warning is harmless and can safely be ignored. I will send a
patch to the xemacs maintainers to get rid of it, and meanwhile
add a patch file to our port.
things so that it uses the same malloc as is used by the program
being executed. This has several advantages, the big one being
that you can now debug core dumps from dynamically linked programs
and get useful information out of them. Until now, that didn't
work. The internal malloc package placed the tables describing
the loaded shared libraries in a mapped region of high memory that
was not written to core files. Thus the debugger had no way of
determining what was loaded where in memory. Now that the dynamic
linker uses the application's malloc package (normally, but not
necessarily, the system malloc), its tables end up in the regular
heap area where they will be included in core dumps. The debugger
now works very well indeed, thank you very much.
Also ...
Bring the program a little closer to conformance with style(9).
There is still a long way to go.
Add minimal const correctness changes to get rid of compiler warnings
caused by the recent const changes in <dlfcn.h> and <link.h>.
Improve performance by eliminating redundant calculations of symbols'
hash values.
Implemented reading of %fs and %gs from core files.
Print weird floating point values better. We have to convert long
doubles to doubles here because of limitations and bugs in printf()
and floatformat_to_double() (long doubles aren't really supported
and naive converion to double causes exceptions). Conversion loses
information about weird formats (everything becomes a quiet NaN),
and printf() doesn't know about different types of NaNs anyway.
plain 0 should be used. This happens to work because we #define
NULL to 0, but is stylistically wrong and can cause problems
for people trying to port bits of code to other environments.
PR: 2752
Submitted by: Arne Henrik Juul <arnej@imf.unit.no>
