Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
Programming
Programmer's Guide
The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
Processes
Your applications should be written in a way that reflects the architecture of the QNX OS—as a set of cooperating processes. In this chapter, we see how to start processes (also known as creating processes) from code, how to terminate them, and how to detect their termination.
Controlling processes via the /proc filesystem
Implemented by the Process Manager component of procnto, the /proc virtual filesystem lets you access and control the processes and threads running in the system.
DCMD_PROC_BREAK
Set or remove a breakpoint or watchpoint in the process that's associated with the file descriptor.

QNX Momentics IDE User's Guide
This User's Guide describes version 8.0 of the Integrated Development Environment (IDE) that's part of the QNX Tool Suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
- Quickstart Guide
- System Architecture
  The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
- OS Components & Operations
- Graphics
- Programming
  - Getting Started with the QNX OS
    Getting Started with the QNX OS: A Guide for Realtime Programmers is intended to introduce you to the QNX OS and help you develop applications and resource managers for it.
  - Programmer's Guide
    The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
    - Compiling and Debugging
      Let's start by looking at some things you should consider when you start to write a program for the QNX OS.
    - QNX OS Architecture and Concepts
      The QNX OS architecture consists of the microkernel and several cooperating processes. These processes communicate with each other via various forms of interprocess communication (IPC). Message passing is the primary form of IPC in QNX OS.
    - Processes
      Your applications should be written in a way that reflects the architecture of the QNX OS—as a set of cooperating processes. In this chapter, we see how to start processes (also known as creating processes) from code, how to terminate them, and how to detect their termination.
      - Starting processes: two methods
        In embedded applications, there are two typical approaches to starting your processes at boot time.
      - Process creation
        The process manager component of procnto is responsible for process creation. If a process wants to create another process, it makes a call to one of the process-creation functions, which then effectively sends a message to the process manager.
      - Process termination
      - Detecting process termination
        In an embedded application, it's often important to detect if any process terminates prematurely and, if so, to handle it.
      - Stack allocation
        Each thread has its own stack that you can allocate yourself or have the system manage.
      - Process privileges
        In systems where security is important, applications should run with the fewest privileges possible. This practice helps reduce the impact of possible compromises and can also help lower the privilege escalation attack surface of the device.
      - Controlling processes via the /proc filesystem
        Implemented by the Process Manager component of procnto, the /proc virtual filesystem lets you access and control the processes and threads running in the system.
        Reading and writing the process's address space
        If you have the appropriate permissions, you can access a process's address space. Since threads exist in the context of a process and have access to everything within a process, there's no need to consider threads in this discussion.
        Manipulating a process or thread
        Once you have a file descriptor to a particular process's /proc/pid/ctl file, you can get information about and control that process and its associated threads.
        Thread information
        Several of the devctl() commands use a procfs_status structure (which is the same as debug_thread_t), so let's look at this structure before going into the commands themselves.
        DCMD_PROC_ABILITIES
        Return all the abilities and ability ranges of a specified process
        DCMD_PROC_BREAK
        Set or remove a breakpoint or watchpoint in the process that's associated with the file descriptor.
        DCMD_PROC_CHANNELS
        Get information about the channels owned by the specified process.
        DCMD_PROC_CLEAR_FLAG
        Clear specific debug flags with the values provided for the process associated with the file descriptor.
        DCMD_PROC_CURTHREAD
        Switch to another thread.
        DCMD_PROC_EVENT
        Define an event to be delivered when the process associated with the file descriptor reaches a point of interest.
        DCMD_PROC_GETALTREG
        Get the information stored in the alternate register set for the process associated with the file descriptor.
        DCMD_PROC_GETFPREG
        Get the information stored in the Floating Point Data registers for the process associated with the file descriptor.
        DCMD_PROC_GETGREG
        Get the information stored in the CPU registers based on the current thread of the process associated with the file descriptor.
        DCMD_PROC_GETREGSET
        Read the given register set.
        DCMD_PROC_GET_BREAKLIST
        Get a list of the active breakpoints for the process associated with the file descriptor.
        DCMD_PROC_INFO
        Obtain information about the process associated with the file descriptor.
        DCMD_PROC_IRQS
        Get information about the interrupts that the process associated with the file descriptor has attached to.
        DCMD_PROC_MAPDEBUG
        Get the best guess to the ELF object on the host machine.
        DCMD_PROC_MAPDEBUG_BASE
        Get information about the path for the process associated with the file descriptor.
        DCMD_PROC_MAPINFO
        Obtain segment-specific information about mapped memory segments in the process associated with the file descriptor. This call matches the corresponding mmap() calls.
        DCMD_PROC_PAGEDATA
        Obtain page data about mapped memory segments in the process associated with the file descriptor. This call matches the corresponding mmap() calls.
        DCMD_PROC_PTINFO
        Return the pagetable mapping information for a memory segment
        DCMD_PROC_RUN
        Resume the process that's associated with the file descriptor, if it has previously been stopped.
        DCMD_PROC_SETALTREG
        Set the alternate register set with the values provided for the process associated with the file descriptor.
        DCMD_PROC_SETFPREG
        Set the Floating Point Data registers with the values provided for the process associated with the file descriptor.
        DCMD_PROC_SETGREG
        Set the CPU registers with the values provided for the process associated with the file descriptor.
        DCMD_PROC_SETREGSET
        Set the given register set.
        DCMD_PROC_SET_FLAG
        Set specific debug flags with the values provided for the process associated with the file descriptor.
        DCMD_PROC_SIGNAL
        Drop a signal on the process that's associated with the file descriptor. This is a way for a debugger to artificially generate signals as if they came from the system.
        DCMD_PROC_STATUS
        Get the current status of the current thread in the process associated with the file descriptor.
        DCMD_PROC_STOP
        Stop the process that's associated with the file descriptor.
        DCMD_PROC_SYSINFO
        Obtain information stored in the system page.
        DCMD_PROC_THREADCTL
        Perform a ThreadCtl() on another process/thread.
        DCMD_PROC_TIDSTATUS
        Get the current status of a thread in the process associated with the file descriptor.
        DCMD_PROC_TIMERS
        Get the timers owned by the process associated with the file descriptor.
    - Multicore Processing
      Multiprocessing systems, whether discrete or multicore, can greatly improve your applications' performance.
    - Working with Access Control Lists (ACLs)
      Some filesystems, such as the Power-Safe (fs-qnx6.so) filesystem, extend file permissions with Access Control Lists, which are based on the withdrawn IEEE POSIX 1003.1e and 1003.2c draft standards.
    - Understanding the Microkernel's Concept of Time
      Whether you're working with timers or simply getting the time of day, it's important that you understand how the OS works with time.
    - Handling Hardware Interrupts
      This chapter explains the QNX OS mechanisms for quickly reacting to hardware events.
    - Working with Memory
      (or The Persistence of Memory, with a nod to Salvador Dali) In the Process Manager chapter of the System Architecture guide, we looked at how the OS manages memory. This chapter describes how you can work with memory.
    - Freedom from Hardware and Platform Dependencies
      The QNX OS can run on many different hardware platforms. The way in which applications can access peripheral devices and how data is stored varies between platforms. This chapter explains our solutions for minimizing the impact of such platform dependencies.
    - Conventions for Recursive Makefiles and Directories
      In this chapter, we'll look at the supplementary files used in the QNX OS development environment. Although we use the standard make command to create libraries and executables, we also use some of our own conventions in the Makefile syntax.
    - Glossary
  - Writing a Resource Manager
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX OS system and developers who want to create a QNX OS resource manager free from vulnerabilities.
- Utilities & Libraries
- Migrating to QNX OS 8.0
QNX Software in the Cloud
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX^® Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX^® Operating System (OS) applications and systems.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation, explains how to obtain technical support, and provides some information about licensing.

DCMD_PROC_BREAK

QNX SDP8.0Programmer's GuideDeveloper

Set or remove a breakpoint or watchpoint in the process that's associated with the file descriptor.

#include <sys/procfs.h>

#define DCMD_PROC_BREAK    (__DIOTF(_DCMD_PROC, __PROC_SUBCMD_PROCFS + 14, procfs_break))

The arguments to devctl() are:


Argument	Value
`filedes`	A file descriptor for the process. You must have opened the file descriptor for writing.
`dcmd`	DCMD_PROC_BREAK
`dev_data_ptr`	A pointer to a procfs_break structure
`n_bytes`	`sizeof(procfs_break)`
`dev_info_ptr`	NULL

The argument is a pointer to a procfs_break structure (see debug_break_t in <sys/debug.h>) that specifies the breakpoint to be set or removed. For example:

procfs_break        brk;

memset(&brk, 0, sizeof brk);
brk.type = _DEBUG_BREAK_EXEC;
brk.addr = acc->break_addr.offset;
brk.size = 0;
devctl(fd, DCMD_PROC_BREAK, &brk, sizeof brk, 0);

To set a breakpoint, use a size of 0 in the procfs_break structure. Additionally, to set a watchpoint, specify the width of the watchpoint area through the size field in the procfs_break structure, which ranges from 1 to 8 bytes. A size of -1 is used to delete either a breakpoint or a watchpoint.

The types of breakpoints; one of the following:

_DEBUG_BREAK_EXEC — execution breakpoint.
_DEBUG_BREAK_RD — read access watchpoint.
_DEBUG_BREAK_WR — write access watchpoint.
_DEBUG_BREAK_RW — read or write access watchpoint.
_DEBUG_BREAK_MODIFY — memory modified watchpoint.
_DEBUG_BREAK_RDM — read access watchpoint if supported; otherwise downgraded.
_DEBUG_BREAK_WRM — write access watchpoint if supported; otherwise downgraded.
_DEBUG_BREAK_RWM — read or write access watchpoint if supported; otherwise downgraded.

Note:

Unsupported access modes with no close behavioral approximation are rejected with an error. Otherwise, a supported approximation is made from the requested access mode.
Breakpoints other than _DEBUG_BREAK_EXEC are highly dependent on the hardware. In many architectures, other types of breakpoints cause the kernel to make the process run in single-step, checking the watchpoints each time, which can be very slow.

Page updated: August 09, 2024