I'm trying to build the dtrace target in the Xcode project using the
advice here:
http://osx86.boeaja.info/2009/10/building-xnu-kernel-on-snow-leopard/
But I get:
libproc.m:24:49: error: CoreSymbolication/CoreSymbolication.h: No such
file or directory
I realize CoreSymbolication is a private framework, but Apple must
make this header available somewhere in order for me to build dtrace,
right? Can someone point me to the necessary files to build dtrace?
As you probably figured out, Apple only has to release parts of the kernel which are taken from other open-source projects, and that doesn't include the userland libraries that they build on top of the kernel. CoreSymbolication/CoreSymbolication.h sounds a lot like a userspace header for Obj-C though, so you can probably build the kernel DTrace utilities without it. (Although I could very well be wrong.)
I would guess it's being used for symbol identification in the userland dtrace(1m) command. If only there was a tool that could help us figure this out... :-D
# dtrace -n 'pid$target:CoreSymbolication::entry {}' -c 'dtrace -ln syscall::write:entry'
dtrace: description 'pid$target:CoreSymbolication::entry ' matched 246 probes
ID PROVIDER MODULE FUNCTION NAME
147 syscall write entry
dtrace: pid 88089 has exited
CPU ID FUNCTION:NAME
2 6538 CSSymbolOwnerGetRegionWithName:entry
2 5014 CSSymbolOwnerForeachRegionWithName:entry
2 5078 CSRegionForeachSymbol:entry
2 6495 CSSymbolicatorGetSymbolOwnerWithUUIDAtTime:entry
2 6493 CSSymbolicatorForeachSymbolOwnerWithUUIDAtTime:entry
2 6494 CSSymbolicatorForeachSymbolOwnerWithCFUUIDBytesAtTime:entry
2 5048 CSSymbolOwnerGetDataFlags:entry
2 6538 CSSymbolOwnerGetRegionWithName:entry
2 5014 CSSymbolOwnerForeachRegionWithName:entry
2 5078 CSRegionForeachSymbol:entry
2 5092 CSSymbolIsExternal:entry
2 5092 CSSymbolIsExternal:entry
...
It looks like the library is in use by the dtrace command, anyway.
Related
I've installed GnuCOBOL 2.2 on my Ubuntu 17.04 system. I've written a basic hello world program to test the compiler.
1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. HELLO-WORLD.
3 *---------------------------
4 DATA DIVISION.
5 *---------------------------
6 PROCEDURE DIVISION.
7 DISPLAY 'Hello, world!'.
8 STOP RUN.
This program is entitled HelloWorld.cbl. When I compile the program with the command
cobc HelloWorld.cbl
HelloWorld.so is produced. When I attempt to run the compiled program using
cobcrun HelloWorld
I receive the following error:
libcob: entry point 'HelloWorld' not found
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
According to the official manual of GNUCOBOL, you should compile your code with:
cobc -x HelloWorld.cbl
then run it with
./HelloWorld
You can also read GNUCOBOL wiki page which contains some exmaples for further information.
P.S. As Simon Sobisch said, If you change your file name to HELLO-WORLD.cbl to match the program ID, the same commands that you have used will be ok:
cobc HELLO-WORLD.cbl
cobcrun HELLO-WORLD
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
An entry point is a point where you may enter a shared object (this is actually more C then COBOL).
GnuCOBOL generates entry points for each PROGRAM-ID, FUNCTION-ID and ENTRY. Therefore your entry point is HELLO-WORLD (which likely gets a conversion as - is no valid identifier in ANSI C - you won't have to think about this when CALLing a program as the conversion will be done internal).
Using cobcrun internally does:
search for a shared object (in your case HelloWord), as this is found (because you've generated it) it will be loaded
search for an entry point in all loaded modules - which isn't found
There are three possible options to get this working:
As mentioned in Ho1's answer: use cobc -x, the reason that this works is because you don't generate a shared object at all but a C main which is called directly (= the entry point doesn't apply at all)
preload the shared object and calling the program by its PROGRAM-ID (entry point), either manually with COB_PRE_LOAD=HelloWorld cobcrun HELLO-WORLD or through cobcrun (option available since GnuCOBOL 2.x) cobcrun -M HelloWorld HELLO-WORLD
change the PROGRAM-ID to match the source name (either rename or change the source, I'd do the second: PROGRAM-ID. HelloWorld.)
I have followed step by step the tutorial to install Veins, but when I tried running the example scenario (final step) I ended up with the above error.
The whole error was:
Error in module (cModule) RSUExampleScenario (id=1) during network
setup: Class "Veins::ObstacleControl" not found -- perhaps its code
was not linked in, or the class wasn't registered with
Register_Class(), or in the case of modules and channels, with
Define_Module()/Define_Channel().
TRAPPING on the exception above, due to a debug-on-errors=true
configuration option. Is your debugger ready?
Simulation terminated with exit code: -2147483645 Working directory:
C:/Users/user/src/veins-4.3/examples/veins Command line:
../../../omnetpp-4.6/bin/opp_run.exe -r 0 -n .;../../src/veins
--tkenv-image-path=../../images -l ../../src/veins omnetpp.ini
I don't think I have missed a step during the tutorial as I have tried it two times. I did not make any change in anything, I've just strictly followed the tutorial like a robot, so I cannot provide an MCVE with more details than the tutorial.
Here is what I'm using:
- Windows 7 Pro 64 bits
- SUMO 0.25.0 64 bits
All other steps of the tutorial successfully worked until the final step.
I assume this error occurs when running Veins via the OMNeT++ IDE. Or, if you have compiled it with GCC (The error does not happen if you use CLANG)
There are two ways to bypass this error:
Use the .run as executable from your examples directory, which calls veins/run and includes all the required libraries:
Use opp_run as executable and set dynamic libraries to the directory where libveins.so is located (usually src/veins)
PS: to answer #ChristopSommer questions: Veins::ObstacleControl appears in opp_run -l src/veins -h classes
This could be a solution too, but I never tested it: Compiler flags in Eclipse
I'm updating the driver of one of my devices and would like to kextunload the old driver and kextload the new one so a restart isn't required anymore.
After the installation I try:
sudo kextunload /System/Library/Extensions/Driver.kext
The error which happens looks like this:
(kernel) Can't unload kext com.driver.Driver; classes have instances:
(kernel) Kext com.driver.Driver class com_driver_Driver_USBAudioDevice has 1 instance.
Failed to unload com.driver.Driver - (libkern/kext) kext is in use or retained (cannot unload).
The device is not present in ioreg.
How can I find out what this instance is which prevents me from unloading the driver?
If you call the command kextstat, it will display a list of all the loaded kernel extensions with info like this one:-
115 3 0xffffff7f814f4000 0x32000 0x32000 com.apple.iokit.IOAudioFamily (1.8.9fc11) <114 5 4 3 1>
The first number (115) is the id of the kernel extension.
At the end, the set of numbers <114 5 4 3 1> are the other kernel extension ids that are being referenced by this particular kext.
If you match the id of your kext to any of those listed in another, then that is a reference that kextunload is referring to.
Also note that when writing any code in the kernel, globals variables are global across the whole kernel, so if you've declared any that may not have a unique name and is used by another kext, I have found this to cause a similar issue. The solution here is to prepend any globals with a reverse company URI (e.g. com_apple_globalVarName).
The accepted answer is incorrect. The trailing numbers at the end of output from kextstat are NOT a listing of the kexts dependent on this one.
They ARE a list of the kexts that this kext is dependent upon.
Using the same example kext as the other answer, com.apple.iokit.IOAudioFamily, I show the following:
~ root# kmutil showloaded -b com.apple.iokit.IOAudioFamily
No variant specified, falling back to release
Index Refs Address Size Wired Name (Version) UUID <Linked Against>
152 3 0xffffff7f9922c000 0x1e000 0x1e000 com.apple.iokit.IOAudioFamily (340.2) 2BC68A45-C1C1-30D1-A7A2-B911CFDB04F2 <151 7 6 3 1>
(Note: I am using kmutil showloaded instead of kextstat as the later is deprecated.)
Breaking this output down we see:
A Refs count of 3 indicates that 3 other kexts "refer" (or link against) this kext.
The <Linked Against> list indicates the Index of other kexts that this kext is dependent upon.
To specifically answer your question, you need to find the other kexts that have your kext's Index listed in their <Linked Against> listing.
Continuing our example with the com.apple.iokit.IOAudioFamily kext we can look at all loaded kexts and search for any referencing index 152 by running: kmutil showloaded | grep '<.*152.*>'
~ root# kmutil showloaded | grep '<.*152.*>'
No variant specified, falling back to release
153 0 0xffffff7f99023000 0x52000 0x52000 com.apple.driver.AppleUSBAudio (416.2) D9A996CC-8118-3E85-B019-F756AC2A4689 <152 150 114 24 23 16 8 7 6 3 1>
190 0 0xffffff7f97a97000 0x5f000 0x5f000 com.apple.driver.AppleGFXHDA (140.3) EED41AF8-3465-37CC-AB65-DB85BD71B595 <152 144 134 16 9 8 7 6 3 1>
219 0 0xffffff7f990ad000 0x3000 0x3000 com.apple.driver.AudioAUUC (1.70) 5C4939F8-12C1-39BF-AD87-8456A450BCF7 <152 134 16 15 9 7 6 3 1>
As you can see, the three kexts that reference (or are Linked Against) com.apple.iokit.IOAudioFamily are:
com.apple.driver.AppleUSBAudio
com.apple.driver.AppleGFXHDA
com.apple.driver.AudioAUUC
You would need to unload these three kexts (and any kexts that they are referenced by in turn) before you could unload the original.
I am trying to use GDB to debug a Linux kernel zImage before it is decompressed. The kernel is running on an ARM target and I have a JTAG debugger connected to it with a GDB server stub. The target has to load a boot loader. The boot loader reads the kernel image from flash and puts it in RAM at 0x20008000, then branches to that location.
I have started GDB and connected to the remote target, then I use GDB's add-symbol-file command like so:
add-symbol-file arch/arm/boot/compressed/vmlinux 0x20008000 -readnow
When I set a breakpoint for that address, it does trap at the correct place - right when it branches to the kernel. However, GDB shows the wrong line from the source of arch/arm/boot/compressed/head.S. It's 4 lines behind. How can I fix this?
I also have tried adding the -s section addr option to add-symbol-file with -s .start 0x20008000; this results in exactly the same problem.
There are assembler macros that print out stuff when compiling with low level debug. You have to make sure the macros are appropriate for your board.
linux-latest/arch/arm$ find . -name debug-macro.S | wc
56 56 2306
Find the file for your board and ensure the correct serial port registers are hit. You can instrument the code with out using JTAG. These macros are used in the decompress code. Of course configure with *CONFIG_DEBUG_LL*.
Most likely the ATAGs are not correct or one of the other requirements. Checkout Documentation/arm/Booting to make sure you have registers set properly. Note there is a new requirement with recent kernels to send a dt list.
I'm compiling a custom kernel under Ubuntu and I'm running into the problem that my kernel doesn't seem to know where to look for firmware. Under Ubuntu 8.04, firmware is tied to kernel version the same way driver modules are. For example, kernel 2.6.24-24-generic stores its kernel modules in:
/lib/modules/2.6.24-24-generic
and its firmware in:
/lib/firmware/2.6.24-24-generic
When I compile the 2.6.24-24-generic Ubuntu kernel according the "Alternate Build Method: The Old-Fashioned Debian Way" I get the appropriate modules directory and all my devices work except those requiring firmware such as my Intel wireless card (ipw2200 module).
The kernel log shows for example that when ipw2200 tries to load the firmware the kernel subsystem controlling the loading of firmware is unable to locate it:
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2
errno-base.h defines this as:
#define ENOENT 2 /* No such file or directory */
(The function returning ENOENT puts a minus in front of it.)
I tried creating a symlink in /lib/firmware where my kernel's name pointed to the 2.6.24-24-generic directory, however this resulted in the same error. This firmware is non-GPL, provided by Intel and packed by Ubuntu. I don't believe it has any actual tie to a particular kernel version. cmp shows that the versions in the various directories are identical.
So how does the kernel know where to look for firmware?
Update
I found this solution to the exact problem I'm having, however it no longer works as Ubuntu has eliminated /etc/hotplug.d and no longer stores its firmware in /usr/lib/hotplug/firmware.
Update2
Some more research turned up some more answers. Up until version 92 of udev, the program firmware_helper was the way firmware got loaded. Starting with udev 93 this program was replaced with a script named firmware.sh providing identical functionality as far as I can tell. Both of these hardcode the firmware path to /lib/firmware. Ubuntu still seems to be using the /lib/udev/firmware_helper binary.
The name of the firmware file is passed to firmware_helper in the environment variable $FIRMWARE which is concatenated to the path /lib/firmware and used to load the firmware.
The actual request to load the firmware is made by the driver (ipw2200 in my case) via the system call:
request_firmware(..., "ipw2200-bss.fw", ...);
Now somewhere in between the driver calling request_firmware and firmware_helper looking at the $FIRMWARE environment variable, the kernel package name is getting prepended to the firmware name.
So who's doing it?
From the kernel's perspective, see /usr/src/linux/Documentation/firmware_class/README:
kernel(driver): calls request_firmware(&fw_entry, $FIRMWARE, device)
userspace:
- /sys/class/firmware/xxx/{loading,data} appear.
- hotplug gets called with a firmware identifier in $FIRMWARE
and the usual hotplug environment.
- hotplug: echo 1 > /sys/class/firmware/xxx/loading
kernel: Discard any previous partial load.
userspace:
- hotplug: cat appropriate_firmware_image > \
/sys/class/firmware/xxx/data
kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
comes in.
userspace:
- hotplug: echo 0 > /sys/class/firmware/xxx/loading
kernel: request_firmware() returns and the driver has the firmware
image in fw_entry->{data,size}. If something went wrong
request_firmware() returns non-zero and fw_entry is set to
NULL.
kernel(driver): Driver code calls release_firmware(fw_entry) releasing
the firmware image and any related resource.
The kernel doesn't actually load any firmware at all. It simply informs userspace, "I want a firmware by the name of xxx", and waits for userspace to pipe the firmware image back to the kernel.
Now, on Ubuntu 8.04,
$ grep firmware /etc/udev/rules.d/80-program.rules
# Load firmware on demand
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware_helper"
so as you've discovered, udev is configured to run firmware_helper when the kernel asks for firmware.
$ apt-get source udev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 312kB of source archives.
Get:1 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (dsc) [716B]
Get:2 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (tar) [245kB]
Get:3 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (diff) [65.7kB]
Fetched 312kB in 1s (223kB/s)
gpg: Signature made Tue 14 Apr 2009 05:31:34 PM EDT using DSA key ID 17063E6D
gpg: Can't check signature: public key not found
dpkg-source: extracting udev in udev-117
dpkg-source: unpacking udev_117.orig.tar.gz
dpkg-source: applying ./udev_117-8ubuntu0.2.diff.gz
$ cd udev-117/
$ cat debian/patches/80-extras-firmware.patch
If you read the source, you'll find that Ubuntu wrote a firmware_helper which is hard-coded to first look for /lib/modules/$(uname -r)/$FIRMWARE, then /lib/modules/$FIRMWARE, and no other locations. Translating it to sh, it does approximately this:
echo -n 1 > /sys/$DEVPATH/loading
cat /lib/firmware/$(uname -r)/$FIRMWARE > /sys/$DEVPATH/data \
|| cat /lib/firmware/$FIRMWARE > /sys/$DEVPATH/data
if [ $? = 0 ]; then
echo -n 1 > /sys/$DEVPATH/loading
echo -n -1 > /sys/$DEVPATH/loading
fi
which is exactly the format the kernel expects.
To make a long story short: Ubuntu's udev package has customizations that always look in /lib/firmware/$(uname -r) first. This policy is being handled in userspace.
Wow this is very useful information and it led me to the solution for my problem when making a custom USB kernel module for a device requiring firmware.
Basically, every Ubuntu brings a new rehash of hal,sysfs,devfs,udev,and so on...and things just change. In fact I read they stopped using hal.
So let's reverse engineer this yet again so it's pertinent to the latest [Ubuntu] systems.
On Ubuntu Lucid (the latest at time of writing), /lib/udev/rules.d/50-firmware.rules is used. This file calls the binary /lib/udev/firmware, where magic happens.
Listing: /lib/udev/rules.d/50-firmware.rules
# firmware-class requests, copies files into the kernel
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
The magic should be something along these lines (source: Linux Device Drivers, 3rd Ed., Ch. 14: The Linux Device Model):
echo 1 to loading
copy firmware to data
on failure, echo -1 to loading and halt firmware loading process
echo 0 to loading (signal the kernel)
then, a specific kernel module receives the data and pushes it to the device
If you look at Lucid's source page for udev, in udev-151/extras/firmware/firmware.c, the source for that firmware /lib/udev/firmware binary, that's exactly what goes on.
Excerpt: Lucid source, udev-151/extras/firmware/firmware.c
util_strscpyl(datapath, sizeof(datapath), udev_get_sys_path(udev), devpath, "/data", NULL);
if (!copy_firmware(udev, fwpath, datapath, statbuf.st_size)) {
err(udev, "error sending firmware '%s' to device\n", firmware);
set_loading(udev, loadpath, "-1");
rc = 4;
goto exit;
};
set_loading(udev, loadpath, "0");
Additionally, many devices use an Intel HEX format (textish files containing checksum and other stuff) (wiki it i have no reputation and no ability to link). The kernel program ihex2fw (called from Makefile in kernel_source/lib/firmware on .HEX files) converts these HEX files to an arbitrary-designed binary format that the Linux kernel then picks up with request_ihex_firmware, because they thought reading text files in the kernel was silly (it would slow things down).
On current Linux systems, this is handled via udev and the firmware.agent.
Linux 3.5.7 Gentoo, I have the same issue.
SOLVED:
emerge ipw2200-firmware
Then go to /usr/src/linux
make menucofig
on device driver, remove all wirless drivers don't needed, set Intell 2200 as module and recompile.
make
make modules_install
cp arch/x86/boot/bzImage /boot/kernel-yourdefault