Using the Development Environment


This section presents specific information on building, debugging, and automation in the Platform SDK, Visual Studio, and Interix development environments. Each environment has specific tools and advantages.

Using the Platform SDK

The Platform SDK includes a comprehensive set of debugging facilities, as described in Table 7.7 on the next page.

Microsoft debugging tools first generate the proper work files by using compile-time options. Developers must decide what level of symbols to generate. The debug environment also plays a role.

Debug information is typically generated by using one of the options shownin Table 7.7.

Table 7.7: Options for Generating Debug Information

Option

Use

/Zi

Creates a program debug database (.pdb) file. The debugger uses this file to step through the source during program execution.

/ZI

Similar to /Zi . However, the .pdb file also supports edit and continue.

/RTCc

Reports runtime truncation error

/RTCs

Enables runtime stack checking, include overrun and under-run of local variables ,and stack register verification.

/RTCu

Enables reporting of variables used without initialization.

/RTC1

Combination of RTCs and RTCu

/Zd

Generates line number information.

/Yd

Places debug information in the .obj files.

Any programs written in languages that support the creation of the .pdb files can be used in the Windows debug environment. Thus, a developer can debug an application source file where calls are made between C, C++, and Fortran.

A developer can use the Platform SDK WinDBG tool to open a source file, then run the corresponding debug version of an executable file. WinDBG searches for debug symbol information for the modules that the executable file uses in the symbol image path .

To use WinDBG to debug an executable file

  1. From the GUI, open the source file corresponding to the executable file to debug.

  2. Set the path for the symbols needed to debug the executable file.

  3. Set desired breakpoints in the source file.

  4. Open the executable file.

Other options for using WinDBG include:

  • Attach to a running process.

  • Open a crash dump file.

  • Use a remote debug session to connect to another system.

The command debugger (CMD) can also be used to debug programs. CMD is especially useful for debugging a running program or for debugging remotely. CMD also can analyze crash dumps by using symbols. For example, this codeuses CDB to analyze a crash dump file:

 cdb y <Symbol Path>  -i <Image Path> -z <Dumpfile> 

Using Visual Studio

When migrating a development environment from UNIX to Windows, one goalis usually to leverage the Visual Studio development tools. However, it can appear to be a large manual task to manage the creation and administration of Visual Studio projects. This is especially true for large projects with hundreds or thousands of sources.

To support developer productivity, Visual Studio provides debugging and automation facilities, which are particularly useful for repetitious tasks .

Debugging with Visual Studio

To debug a program using Visual Studio, the program must be compiled with the appropriate options set. (For more information about the options, see the list in Using the Platform SDK earlier in this chapter.) To use the Visual Studio debugger, in the configuration manager, set the active configuration to debug. When the project is compiled, the debug session can begin.

You can run a debug session within a project opened in the Visual Studio 6.0 or by opening a remote connection from the IDE. You can choose either option from the Build menu in the Visual Studio IDE.

This section covers local debug sessions. You can start a local debug session by selecting Start debug on the Build menu, and then either starting the programto be debugged or attaching debug to a running process.

A developer can control a debug session through menu options or toolbars in the Visual Studio 6.0 IDE, or through the use of shortcut keys. A top-level debug is created once a debug session starts. The Debug menu includes the symbol for the toolbar button that accomplishes the same command. Table 7.8 describes the commonly used debug commands.

Table 7.8: Debug Commands

Command

Description

Go

Menu item “ Build->Start Debugging->Go
Shortcut “ F5

Step Into

Menu item “ Debug->Step Into
Shortcut “ F11

Step Over

Menu item “ Debug->Step Over
Shortcut “ F10

Step Out

Menu Item “ Debug->Step Out
Shortcut “ Shift+F11

Run to Cursor

Menu item “ Debug->Run to Cursor
Shortcut “ CTRL+F10

Stop Debugging

Menu item “ Debug->Stop Debugging
Shortcut “ Shift+F5

Restart

Menu Item “ Debug->Restart
Shortcut “ CTRL+Shift+F5.

Set Break Point

First move the cursor to the line in the source file where you want a breakpoint.
Menu item “ Right-click line in source, then select Set Break Point Shortcut “ CTRL+B

– To start a debug session

  1. Set a breakpoint in the source where the debug execution will stop: Right-click the appropriate line in the source, and then select Insert breakpoint or press CTRL+B.

  2. On the IDE Debug menu, select Start , or press F5.

    The program executes until the breakpoint is reached. At the breakpoint, fromthe Debug menu you can view local variables, the call stack, registers, memory, processes, and threads from windows.

  3. To continue, set another breakpoint. Press F5 to continue, press F11 to stepinto the next line of code, press F10 to step over the next code line, or positionthe cursor to the next line to stop and select Run to cursor .

This process continues until you terminate the debug session, the program abnormally terminates, or the program terminates normally.

Developers can use the Visual Studio edit and continue feature during a debug session to change the source and then recompile. If the developer changes the source while debug execution is paused (such as at a breakpoint), the debugger can compile the change before proceeding with the debug session. To enable this feature, compile the source with the “ZI option.

Automation with Macros

Macros are built by using Visual Basic for Applications (VBA). The VBA IDE canbe invoked from within Visual Studio.

Macros can automate project generation and maintenance. In a conversion, macros can synchronize with a batch build environment, integrate tools needed to support the Microsoft development environment, or automate any repetitive process used during development. For example, macros can create add-ins or wizards for the Visual Studio IDE.

A wizard can, for example, automate the task of creating a project that supports OpenGL. The wizard offers options such as support for Win32 GUI in the open OpenGL application, or making the OpenGL application console based.

Based on input from the wizard, the appropriate Visual Studio project settings and libraries are included. For example, if Win32 GUI support is needed, the wizard can include the OpenGL graphics library utility toolkit (GLUT) libraries in the project.

Using Interix

The Interix subsystem can be used in conjunction with the Windows Platform SDK or Visual Studio. The SDK, which provides a front end for Microsoft Visual C++, offers the benefits of the native compiler for Windows while retaining a UNIX development environment. But the Interix environment also offers the benefitsof the GNU gcc and g++ compilers.

Differences Between Interix and UNIX

The Interix environment is a UNIX environment, but there are some differences:

  • The Interix SDK can be used to create UNIX-style .so libraries. Although similar to Windows dynamic-link libraries (DLLs), .so libraries are not the same in implementation or semantics.

  • Interix does not have or use the /etc/passwd file (or NIS passwd map file), which typically contains a field with the name of each user s login shell. Therefore, when a user logs on to a system by using Telnet, the login shell is not determined by a shell entry in /etc/password, but by how the Telnet server is configured on the remote system. The Interix telnetd server, which can be configured to be started by the inetd daemon (by entering a line in the inetd.conf file), uses the Korn shell as the default login shell.

    In Interix, user and group information is stored either in a Windows SAM database or in an Active Directory database. The default login shell for Telnet is stored under the User Comment field of a user account. An administrator can change the User Comment field from the command line by using the Windows net command as follows :

    net user logname /usercomment: default shell [ / domain ]

    The logname argument is the name with which the user logs on. The / domain switch is optional if the user logs on from the current domain. For example, the following command sets the default login shell to the C shell for a user named carlos in the current domain:

     net user carlos /usercomment:/bin/csh 
  • On most UNIX systems, when a user logs on to the Korn shell, the shell runsat least two startup files (login scripts), /etc/profile, and $HOME/.profile for setting up the environment. The C shell runs similar scripts, /etc/csh. cshrc and/etc/csh.login, and multiple files in the home directory.

    Interix shells work in a similar way, but include additional files that have the .lcl extension. The Korn shell reads /etc/profile, which calls /etc/profile.lcl. The C shell reads /etc/csh.login, which calls /etc/csh.lcl. Make any local system changes in the .lcl files. These settings affect all users who log on to a shell.

Building Applications with Interix

Applications are built by using Interix in the same way as they are built in the UNIX environment. When building applications in the Interix environment, keep the following considerations in mind:

  • The Interix SDK supports Visual C++ for compiling C programs. It does not support Visual C++ for compiling C++ programs. For C++ programs, the GNU g++ compiler is provided.

  • The version of make provided with the Interix Software Development Kit (SDK) is based on the Berkeley Software Distribution (BSD) 4.4 make and supports all BSD features. It also conforms to POSIX.2. The GNU make ( gmake ) utility can help when porting the application s makefiles.

  • To convert existing makefiles to run under the Interix subsystem, change macro definitions. Edit the value of $(CFLAGS) to use only flags supported by cc or c89 .

  • The Interix SDK supports shared or dynamically linked libraries. Dynamic linking is supported by using standard calls, such as dlopen(). Dynamically linked applications and shared libraries can be created only by using gcc and the other GNU compiler tools.

  • A typical problem when porting a UNIX application to Interix is that on builds, gcc in the Interix SDK defaults to static libraries. To link to the shared libraries, use the compiler option ”dynamic . To force the compiler to link to the static libraries, use the compiler option ”static .

  • Shared libraries should linked to the libc.so library visible to them. It is usually incorrect to link shared libraries to libc.a. Shared libraries should also link to libpsxdll.a, except when a shared library makes no direct calls to libpsxdll.a entry points (the system calls). Because these system calls are located in libpsxdll.a,a dynamic-link library, missing system call errors usually indicate that libpsxdll.a was not included in the linking.

  • The Interix SDK includes the liblock command, which locks a library to prevent the linker from using it. If any process attempts to use a locked library to link,the ld command reports a fatal error. There is no tool provided to unlock a library that has been locked by using liblock . However, locking is vulnerable and is not a high-security option. The syntax is:

     % liblock lib.so 

Although the gcc command understands these rules of linking, use extreme caution if you are invoking ld directly.

For an example of building an application with Interix, see Building and Debugging with Interix later in this chapter.

Running Applications with Interix

On a Windows platform, applications run on specific subsystems and in specific environments. On the Interix subsystem, applications run in a UNIX environment; on the Windows subsystem, applications run in a Windows environment. The following examples illustrate this difference:

  • When running an application that uses the Korn shell or C shell that come with Interix, or any application that was compiled to use the Interix subsystem, the application runs in a UNIX environment. This environment features case-sensitive file names , paths that use the format /usr/examples, and otherparadigms and tools a UNIX developer expects in any UNIX environment.

  • When running an application by using the command processor cmd.exe, the application runs in a Windows environment. In this environment, file namesare not case-sensitive, and paths use the C:\SFU\usr\examples convention.

If the UNIX application to be migrated is a daemon, create symbolic links in /etc/rc2.d to scripts that start and stop it, such as the start and stop scripts from the UNIX environment. Interix programs designed to run as daemons can be controlled by using the usual UNIX mechanisms, such as by using the kill utility to send signals to the program.

The Interix Korn shell follows traditional Korn shell behavior, which is almost identical to POSIX behavior. But for strict POSIX conformance from the Korn shell, run the shell in POSIX mode.

To run the Korn shell in POSIX mode

  1. Invoke the Korn shell with the -o posix option.

  2. Run this command from within the shell: set -o posix .

  3. Set the POSIXLY_CORRECT shell parameter.

The C shell does not support POSIX conformance. Unlike the Korn shell, it has no POSIX-mode command options.

Debugging with Interix

The example given earlier in Building and Debugging with Interix shows how the gdb debugger can be used to debug applications in the Interix environment. Table 7.9 describes the commands available for gdb .

Table 7.9: gdb Commands

Command

Description

run [ args ]

Runs the program with the arguments specified by args . If no argumentsare specified, the last arguments given are used.

break [ address ]

Sets a breakpoint to stop execution at the specified address. The address can be a function name, a line in the current file, a file name and a line number (as in filename : number ), or an offset from the current stop. If no address is given, the breakpoint is set at the next instruction.

continue [ count ]

Continues execution. If count is specified, this breakpoint is ignored for the next count passes .

step [ count ]

Executes until the next line is reached, and repeats count times.

next [ count ]

Executes next line, including function calls, and repeats count times.

list [ address ]

Shows the next 10 lines of source or shows lines around address . The address can be [ filename : ] number , or an offset (indicated by + or - ), or a range indicated by first , last .

backtrace [ n ]

Prints all frames in the stack. If n is positive, prints n innermost frames.If n is negative, prints n outermost frames.

print expression

Prints the value of expression .

quit

Exits gdb.

The gdb debugger also provides a help command for the various operations. To see a list of help issues, type help at the gdb prompt. In addition to gdb, the Interix SDK includes the pstat and truss utilities to help in debugging programs.

The pstat utility displays detailed information about a specified process.

Note  

If you have Administrator privileges (that is, if you are signed on as Administrator and a member of local Administrator group), you can view any process identifier (PID). If you do not have Administrator privileges, you can only view PIDs owned by your shell (that is, launched from your shell).

For example, this is the output for PID 10187 (a C shell process):

 % pstat 10187 pid=10187 ppid=1 pgid=10187 sid=10187 state=3 Active flags=40000022 execed pgrp asleep signal trampoline = 0x77EA1F66,0x77EA1F8F  nullapi = 0x77EA7A07,0x77EA7A4F current syscall=sigsuspend() IP=77f8224d  SP=0088da1c  BP=0088daf8  FL=00000246  AX=00000000  BX=00000001   CX=00000000  DX=00000000  DI=0088eddc  SI=0088da78 CS=0000001b  DS=00000023  ES=00000023  FS=00000038  GS=00000000  SS=00000023 

Although it does not have the same functionality, the truss utility was inspired by the System V utility of the same name. The truss utility outputs information about system calls and signals.

For example, this output represents the system calls made on behalf of the cat concatenate and print files utility:

 % truss cat config.log tracing pid 12491 null() null returned 0 open("config.log", 0x1) open returned 3 fstat(1, 0x1210650, 0x1200650) fstat ret: 0 dev: 0x0 ino: 0x00000000 read(3, 0x8228E0, 512) read returned 127 0x7F write(1, 0x8228E0, 127) This file contains any messages produced by compilers  while running configure, to aid debugging if configure makes a mistake. write returned 127 0x7F read(3, 0x8228E0, 512) read returned 0 close(3) close returned 0 close(1) close returned 0 exit(0) process exited with status 0 



UNIX Application Migration Guide
Unix Application Migration Guide (Patterns & Practices)
ISBN: 0735618380
EAN: 2147483647
Year: 2003
Pages: 134

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net