Monday, March 20, 2006
Tips for the week: March 19 2006
(It's been pretty busy the last couple of weeks so the are lots of tips lately)
Q: I’m building/porting an application for the first time, and I noticed my compile is failing due to __int64 types not being defined. E.g. __time64_t isn’t working and I can’t support 64-bit time without it. Doesn’t OSE support 64-bit access?
A: Yes it does, but not directly. In osetypes.h there is a struct type U64 which defines two 32-bit values and simulates a 64-bit one, using struct members msw and lsw (most significant word, least significant word) to create the full value. You’ll find osetypes.h in different places depending on your release:
OSE5.1: $OSE_ROOT/include
OSE4.x: $OSE_ROOT/powerpc/krn-xxx/include or
$OSE_ROOT/sfk-win32/krn-win32/include
Note that this holds true even if you included - the 64 bit support doesn’t come automatically, you have to adapt your system for it for use with OSE.
Q: I was trying to get gdb going yesterday on my target and I noticed I could not attach it to an ose_* type of process or set a breakpoint inside of an ose_* routine. Is that a limitation with the other debuggers?
A: There is in OSE something that prevents you from attaching to a system process with a debugger (by default), but can be overridden using the SYSTEM_PROCESS macro in ospp.con. Just change it to something other than ose_*. If/when you use GHS Multi, there's also a string in the GHS oseserv you'll need to change with a binary editor to get this capability.
Q: I am debugging with the MULTI plug-in and I cannot see any OSE system processes come up, but I know they’re normally visible. Why can’t I see them?
A: The MULTI plug-in used by Illuminator creates a special custom debug configuration. There are several standard (i.e. non-custom debug configuration types) that allow you to check or un-check a checkbox saying “Hide System Processes,” however in the custom config this is not offered. So you can select OSE (current config used by the Illuminator plug-in) and use that configuration, or just create your own debug config completely and not use the plug-in version at all.
To get to the “Hide System Processes” check box in MULTI, when you bring up the processes window, select
Target -> Show Connection Organizer
In Connection Organizer window, on the top right corner there is a pane with some "User Methods" which are just configurations for connections. Select the currently connected one, which is probably called "OSE," and right-click menu then select "Edit." This brings up the Connection Editor where you'll find find three tabs, and one of those is the "Advanced" tab and under here you’ll find the checkbox for system processes.
Q: I upgraded from 4.6 to 4.6.1. I was using a ported example from the older /examples directory and my shell commands behave differently – when you enter an unknown command for example, the error handling doesn’t look right and the shell login process restarts.
A: 4.6.1 changes many things about the OSE shell. It expects the shell to be a system built by refsys, namely. If you didn’t build with refsys, you might expect some strange behavior particularly in the shell. Two possible workarounds for the unknown command problem:
1) call prh_asf_shell_mode from a start hook, or
2) add a shell_add_cmd call somewhere in your code for a default command. This works well if you didn’t include PRH in your system.
shell_add_cmd("" , "< command > [< parameters >...]", "default shell command", cmd_pgrun);
Q: I’m building/porting an application for the first time, and I noticed my compile is failing due to __int64 types not being defined. E.g. __time64_t isn’t working and I can’t support 64-bit time without it. Doesn’t OSE support 64-bit access?
A: Yes it does, but not directly. In osetypes.h there is a struct type U64 which defines two 32-bit values and simulates a 64-bit one, using struct members msw and lsw (most significant word, least significant word) to create the full value. You’ll find osetypes.h in different places depending on your release:
OSE5.1: $OSE_ROOT/include
OSE4.x: $OSE_ROOT/powerpc/krn-xxx/include or
$OSE_ROOT/sfk-win32/krn-win32/include
Note that this holds true even if you included
Q: I was trying to get gdb going yesterday on my target and I noticed I could not attach it to an ose_* type of process or set a breakpoint inside of an ose_* routine. Is that a limitation with the other debuggers?
A: There is in OSE something that prevents you from attaching to a system process with a debugger (by default), but can be overridden using the SYSTEM_PROCESS macro in ospp.con. Just change it to something other than ose_*. If/when you use GHS Multi, there's also a string in the GHS oseserv you'll need to change with a binary editor to get this capability.
Q: I am debugging with the MULTI plug-in and I cannot see any OSE system processes come up, but I know they’re normally visible. Why can’t I see them?
A: The MULTI plug-in used by Illuminator creates a special custom debug configuration. There are several standard (i.e. non-custom debug configuration types) that allow you to check or un-check a checkbox saying “Hide System Processes,” however in the custom config this is not offered. So you can select OSE (current config used by the Illuminator plug-in) and use that configuration, or just create your own debug config completely and not use the plug-in version at all.
To get to the “Hide System Processes” check box in MULTI, when you bring up the processes window, select
Target -> Show Connection Organizer
In Connection Organizer window, on the top right corner there is a pane with some "User Methods" which are just configurations for connections. Select the currently connected one, which is probably called "OSE," and right-click menu then select "Edit." This brings up the Connection Editor where you'll find find three tabs, and one of those is the "Advanced" tab and under here you’ll find the checkbox for system processes.
Q: I upgraded from 4.6 to 4.6.1. I was using a ported example from the older /examples directory and my shell commands behave differently – when you enter an unknown command for example, the error handling doesn’t look right and the shell login process restarts.
A: 4.6.1 changes many things about the OSE shell. It expects the shell to be a system built by refsys, namely. If you didn’t build with refsys, you might expect some strange behavior particularly in the shell. Two possible workarounds for the unknown command problem:
1) call prh_asf_shell_mode from a start hook, or
2) add a shell_add_cmd call somewhere in your code for a default command. This works well if you didn’t include PRH in your system.
shell_add_cmd("" , "< command > [< parameters >...]", "default shell command", cmd_pgrun);
Labels: 64-bit, gdb, MULTI, OSE4.6.1, shell
free invisible web counter
