crash dumps with kernel modules. The command is basically a wrapper
around add-symbol-file except that it uses the kernel linker data
structures and the ELF section headers of the kld to calculate the
section addresses add-symbol-file needs.
The 'kld' parameter may either be an absolute path or a relative path.
kgdb looks for the kld in several locations checking for variants with
".symbols" or ".debug" suffixes in each location. The first location it
tries is just opening the specified path (this handles absolute paths and
looks for the kld relative to the current directory otherwise). Next
it tries to find the module in the same directory of the kernel image
being used. If that fails it extracts the kern.module_path from the
kernel being debugged and looks in each of those paths.
The upshot is that for the common cases of debugging /boot/kernel/kernel
where the module is in either /boot/kernel or /boot/modules one can merely
do 'add-kld foo.ko'.
MFC after: 1 week
(as a nice side affect, this will make gnu/usr.bin/cvs/contrib/Makefile
have a later date than contrib/cvs/contrib/Makefile.in - which will help
the build break after the 1.11.22 CVS import...)
libraries had not had their versions bumped relative to 6.3-REL but
had indeed been changed. We need to bump their version so they can be
properly added to the compat6x port:
libasn1.so.8 libgssapi.so.8 libhdb.so.8 libkadm5clnt.so.8
libkadm5srv.so.8 libkafs5.so.8 libkrb5.so.8 libobjc.so.2
MFC After: 1 day
- Save td_oncpu in 'struct kthr' so the i386 target code can see which CPU
a thread is running on.
- Add a new frame unwinder for double fault frames. This unwinder is used
when "dblfault_handler" is encountered in the stack. It uses the CPU of
the current thread to lookup the base address of the TSS used for the
double fault from the GDT. It then fetches the various registers out
of the TSS similar to how the current trapframe unwinder fetches
registers out of the trapframe.
MFC after: 3 days
support for these. This is in line with gnu/lib/libgomp/config.h and
gnu/lib/libstdc++/config.h.
Reviewed by: cognet, obrien
Approved by: re (kensmith)
bad code at -O2. Since this is likely caused by the low-level
optimizer, testing TARGET_ARCH rather than MACHINE_ARCH should
handle ia64 cross-compilation as well. With this work-around
in place, we can release using the current GCC and Binutils
code at the default optimization level on ia64.
Approved by: re (kensmith)
Pointy hat to: me and my absence of -Wall in my CFLAGS.
MFC will happen at the same time of the earlier commit.
Thanks to ru@ for spotting.
Approved by: re (Ken Smith), grog@ (mentor)
Some ports will install with compressed manpages. man handles
this by looking for the .gz version of a man source file.
It is also common to include other files with the .so
directive where commands or functions share a man page.
Traditionally ports have had to handle this by either not
compressing the manpages, or using the _MLINKS macro in the
port makefile to create symlinks to the actual source file,
rather than using .so versions. Notably, the current version
of Xorg port breaks. See ports/113096 and ports/115845.
PR: bin/115850
Submitted by: Callum Gibson <callumgibson@optusnet.com.au>
Approved by: re@ (ken smith), grog@ (mentor)
MFC after: 1 week
that need to be activated specifically for the case of a native linker
actually are enabled. Specifically, this makes ld(1) look for shared
libraries in LD_LIBRARY_PATH in the native case, as documented in the
man page.
PR: gnu/96481
Approved by: re (kensmith)
MFC after: 2 weeks
32 bits, so subsequent compile time assertion:
sizeof inf->stat.st_mtime <= sizeof sec
Would fail because of that. This change is suitable for
general consumption as well, but fix it in our local
patchset as we are near a code freeze.
Submitted by: cognet
that the build failure was caused by a computer/sources date/time
mismatch that caused GCC tools to be mistakenly rebuilt again at
an inappropriate time during buildworld, re-linking them against
new libraries instead of host's installed libraries and thus making
them not runnable by the host. Normally they are only built in
the early stage of buildworld (build-tools) that links them against
shared libraries of the host, but if either the system clock or
modification date/time on source files is set incorrectly, make(1)
can be foolished into thinking that tools are stale and will rebuild
them again, now in the "target" environment which is not suitable
for building helper apps that are to be run during buildworld.
OK'ed by: kan
Also:
Switch FreeBSD to use libgcc_s.so.1.
Use dl_iterate_phdr to locate shared objects' exception frame
info instead of depending on older register_frame_info machinery.
This allows us to avoid depending on libgcc_s.so.1 in binaries
that do not use exception handling directly. As an additional
benefit it breaks circular libc <=> libgcc_s.so.1 dependency too.
Build newly added libgomp.so.1 library, the runtime support
bits for OpenMP.
Build LGPLed libssp library. Our libc provides our own
BSD-licensed SSP callbacks implementation, so this library
is only built to benefit applications that have hadcoded
knowledge of libssp.so and libssp_nonshared.a. When linked
in from command line, these libraries override libc
implementation.
'target'. Latter is problematic in particular as apparently FreeBSD's
bsd.prog.mk re-defines it under some circumstances. This causes an
unexpected failures like -dumpmachine not working for cc while working
fine for c++.
Do not re-define IN_GCC in multipe places, it gets inherited from
Makefile.in anyway.
PR: gnu/110143
Submitted by: usleepless at gmail
