Debug C components

You can attach your debugger to the server executable and set breakpoints to step into your component code.

In order to debug components, you must be running the debug version of the server, and use a debugger running on the same host as the server. Chapter 3, “Creating and Configuring Servers,” in the EAServer System Administration Guide describes how to start the debug server.

Debugging your C component

Attach to the EAServer process with your debugger.

Alternatively, start the debugger with the EAServer executable. For example, on UNIX, enter:
```
dbx $JAGUAR/devbin/jagsrv ServerName
```
On Windows, enter:
```
msdev %JAGUAR%\devbin\jagsrv ServerName
```
ServerName is the name of the server. If you are using the preconfigured server rather than one that you created yourself, use “Jaguar.”
Set a breakpoint on the function jag_dbg_stop. This function executes every time the server loads a component DLL. The jag_dbg_stop prototype is:
```
void jag_dbg_stop(char *compName)
```
The compName parameter specifies the name of the library or shared library that was just loaded. Several components may be loaded before yours. In the debugger, display the compName value when the jag_dbg_stop breakpoint is tripped, and monitor the value to determine when your component is loaded. Breakpoints on jag_dbg_stop are triggered before EAServer calls the component’s create method.

Make sure the jag_dbg_stop breakpoint is set before your client application instantiates any stub objects.
When your component’s DLL is loaded, you can specify the component’s C function names as breakpoints and step into the method’s code when it is invoked. Note that the actual C function names exported by the DLL will not match the method names that you see in your source code. The next section describes how to determine the C function names for your methods.

Determining actual function names for your methods

In many operating systems, all functions in a single executable must have unique names. For this reason, the generated skeleton code contains macros that rename each method with a longer name at compile time. The final name is guaranteed to be unique among installed components. You must use these longer names to set breakpoints when debugging.

To view the name mappings, look at the generated skeleton header file for your component. There will be a macro that renames each method. The final method is renamed according to this syntax:

package_component_method

where package is the package name, component is the component name and method is the method name. For example, the component named “sendrows” in a package named “jagdb,” is renamed as follows:

#define    send_rows     jagdb_sendrows_send_rows