Wednesday, August 02, 2006

 

Tips for June 2006

Q: I’m trying to compile an OSE5 sfk-linux target using a Fedora Core host, and getting this link error:

../../../../bin/ld:/usr/lib/libc.so:
file format not recognized; treating as linker script
../../../../bin/ld:/usr/lib/libc.so:5:
parse error

A: The cause is the libc.so directive AS_NEEDED(…). This is present in newer versions of /usr/lib/libc.so, but you’d need a much later version of ld command to interpret it. The ld command is part of the binutils distribution, and Fedora Core FC4 and FC5 both use a binutils that is older hence the ld chokes on AS_NEEDED. You can get around this by just removing the AS_NEEDED(…) clause from libc.so (make a backup copy of the original first of course).

Q: I’m using Eclipse with the gdb debugger and I’m trying to step through some source in my application. When I set a breakpoint in my app source though, the debugger doesn’t ever hit it. It will only hit a breakpoint I set in the disassembly view.

A: If you followed the instructions sent with the Eclipse for OSE User’s Guide, then you’re out of luck. That guide tells you to set up a project with the refsys/rtose/ as your eclipse project home. Any files that you include (as per the instructions) are strictly within the rtose target directory and whatever else the instructions in the manual told you to pull in. Because your application source likely sits outside of this hierarchy (e.g. in modules or somewhere outside the OSE tree), Eclipse doesn’t treat it as part of your project and thus won’t let you use a source-level breakpoint in it.

If you want true source-level debugging throughout your system and are a power-user of Eclipse, you can do the following:
1) create a new project from scratch
2) locate the project at the top of the OSE tree
3) use import to bring in your application code
4) create explicit make targets within refsys/rtose/
5) build your explicit target and debug it
Once you do this you have full source-level debug capability for anything that you imported.


Q: I’m using Eclipse delivered with Optima (new name for the Tools 1.2 release). When I set up my project I immediately see hundereds of indexing warnings in the Problem tab window saying "Preprocessor inclusion not found," usually for sigdb.c or various sigdb-related files. Why are all these indexing warnings showing in the 1.2 Tools release of Eclipse but no in the 1.1 release?

A: By default, when you create a new Eclipse project the C/C++ Indexer is turned on for full indexing. This is a new pull-down listbox option for Tools 1.2 that wasn’t available in Tools 1.1, hence the indexer appears as more sensitive to these types of indexing problems. The simplest way to get rid of this is to add an exclusion filter for the rtose/ subdirectories, since it’s highly unlikely you’d ever want to index anything in there.
To add the exclusion filter:
1) Select project (click on it in the left side C/C++ Projects tab)
2) right mouse click for Project -> Properties
3) select C/C++ Project Paths
4) select tab for Source
5) locate the source folder (you’ll probably only see one for your rtose), and select the “Exclusion filter:” setting underneath it. This will probably be “(none)”. Click “Edit…”
6) Window titled “Source folder for Exclusion Patterns” probably has nothing in it. Click “Add…” to add a filter.
7) You can use wildcards, so add a filter *sigdb* and click OK.
8) Your new filter shows in the Exclusions Patterns list. Click OK again to dismiss.
9) Repeat for the tab for Output.
10) To clean out the existing warnings, you may have to turn off indexing in Properties and click “Apply” then re-enable it.
Your exclusion filters are set up now.

Q: I’m adding a new module in refsys which is C++. When I include networking with inet.h the module compiles and creates a library without problems. But when I compile sfk-win32 rtose, I get this compile error:


$ make ARCH=sfk-win32 FLAVOR=debug all
--- Compiling NDWebsDbg.cpp
In file included from ../../../include/net/if.h:414,
from ../../../include/inet.h:39,
../../../include/sfk/net/sfk_if.h: In function `if_nameindex* if_nameindex()':
../../../include/sfk/net/sfk_if.h:48: error: cannot convert `zzif_nameindex*' to `if_nameindex*' in return

A: In the soft kernel, many calls like this are “mangled” by prepending ZZ or zz to the front, so the local system can distinguish between sfk and other local calls that are the same. The renaming for inlines is done in include/sfk/net/sfk_if.h . The if_nameindex macro uses an object-like macro, i.e "define if_nameindex zzif_nameindex" . In C++ (but not in C), this causes a problem when prototyping without the argument. Attempting to use if_nameindex() does not work either – since it has void within it for C++ purposes, it also generates an error. By using one argument for the ifnameindex() call, the prototype declaration works and GCC compiler seem to be OK with calls to if_nameindex() in the code. ANSI C89 is unclear about how this is supposed to be treated, but for now just change the problem calls to have an argument, e.g.:
$ diff sfk_if.h sfk_if.h.fix
< #define if_nameindex zzif_nameindex
> #define if_nameindex(a) zzif_nameindex(a)


Q: I’m trying to install OSE5 and when it got to the dialog to specify the decryption key file, I entered the keyfile but got an error: "Error reading decryption key file".

A: One of several things could be happening:
- Your keyfile is the wrong release (OSE4 keyfile will cause this misleading error in an OSE5 install)
- Your keyfile is corrupt or missing large components
- Your keyfile was glommed together from several other keyfiles you received, and the sequence in the file cannot be understood by the install program

Check your keyfile to see if the correct version was used, and if the keyfile was generated for your site.

Q: I am trying to write to a file using fprintf and I don't see anything in the file unless I close the file. I have even put an fflush but that doesn't seem to have any effect. I have even tried writing large buffers to see if OSE for efficency reasons really writes to the file only after a threshold size.

A: If this is a new file, or you're writing data to the end of an existing file, then I think you'd need to do an fsync() or efs_sync() on the volume so that the directory will get updated. Otherwise, another process that tries to read the file will be told that it's 0 length (for a new file).

Q: I’m using Illuminator to check my stack sizes. The stack sizes are always reported as being 64K, when in fact I know there are mixed stack sizes (1K, 16K etc). What is going on?

A: In ostarget.con (for OSE4 distributions), there is a SUPERV_SIZE parameter. When the app processes are supervisor mode, and they generally are unless you specified otherwise, then the number that is specified for SUPERV_SIZE in ostarget.con will be added to the size of each stack. In this case, SUPERV_SIZE(23000) was set in the config and that's why illuminator was showing 64K buckets. Reducing this to a more reasonable 1K for the supervisor stack while increasing the user stack to 10K reports stack sizes that are accurate and makes more efficient use of your stack.

Q: This stack is a mystery to me, is there anyway to check outside of Illuminator tools? E.g. System Browser and/or Profiler capabilities in a shell command for OSE?


A: There is no canned shell command for a process, but you can use the Web Surfer built into to OSE4.5 and available as a module in OSE4.6. to get the info. The Surfer executes different functions than are used by the pose_ldm module that Illuminator talks to. You’ll probably still see the same stuff -- processing the stack top and stack limit fields that pose.c maintains. The Surfer is accessible from any web browser. In OSE5.2, the unix "top" command has been ported as a refsys module. This module could (in theory) be backported to OSE5.1 if desired.

Q: Say I have 3 prioritized process with the following priorities:
A: 6 (system management utility)
B: 21 (user 1 shell invoking utility)
C: 21 (user 2 shell invoking same utility)
Process B is in a loop where it sends a signal to A and then waits for A to send a signal back. Process A does not block on anything. It will receive the signal from B and send a signal back immediately. Will process C get a chance to run?


A: No, C process will not get a chance to run unless A or B is yielding some time by sleeping or similar, or if B explicitly tries to signal C. Because B does not actually wait, but is marked ready the entire time, it won't lose its position in the ready queue.

This might be inconvenient in cases where you have a lot of user processes that are the same priority (e.g. user shell) and the process may be executing something that takes a long time and which does not yield (e.g. time-consuming shell command). One way to force the consumer to temporarily go to the end of the queue is to add some code to force resetting of the priority to the same level:

set_pri(get_pri(current_process()));

The act of setting the priority, even though it's being set to the same thing, will cause the caller to go to the end of the queue (at that priority level).

Labels: , , , , ,


Comments: Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?

free web hit counter
free invisible web counter