![](https://csdnimg.cn/release/download_crawler_static/17797530/bg13.jpg)
Diagnostic System User Guide Diagnostic services overview
80-NA157-61 U Confidential and Proprietary – Qualcomm Technologies, Inc. 19
MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
The recover_f3.cmm script is used to extract and process messages from the F3 trace buffer.
In order to recover f3 with Qshrink4:
cd.do <Path>\recover_f3.cmm c:\temp <msg_hash_file (*.qsr4)>
2.3.3.3 Qshrink
The main purpose of Qshrink is to reduce the memory footprint of the builds. This module scans
a full target build, extracts all debug message strings, creates a hash table of these strings, and
modifies the build to use the new hash values instead of the strings to pass to QXDM Pro or other
tools. The hash is computed on the debug string and the file name. Prior to Qshrink 2.0, the
optimization was done by maintaining a hash table for format strings and file names.
This hash table was shared with QXDM Pro and used by the T32 recovery script to reconstruct
the hashed messages from the F3 trace; for example, a 4-byte hash is assigned to the following
debug message with an associated source file:
712406761:diagdiag.c:Diagpkt_alloc returned NULL in diagdiag_peekw.
Qshrink 3.0 additionally hashes the SSID, subsystem mask, and runtime mask associated with the
F3 message. The hash table is added to the modem ELF for runtime filtering and reconstruction
of hashed messages. The reconstruction is currently being done by Diag for QXDM Pro messages
(not needed for an F3 trace), so no change is needed on the QxDM Pro side.
Qshrink 4.0 is the new addition to Qshrink 3.0 to remove debug messages completely from the
modem final image, saving an additional 2 MB over Qshrink 3.0 in modem builds.
The Qshrink4 database file is generated during the build. Each image has its own Qshrink4
database file, unlike Qshrink3 and earlier versions, where the database was generated quarterly.
The Qshrink4 database files are located with the image binaries and must be in a location that is
accessible by the RFS for Diag to access it.
The Qshrink4 database ID is generated during the build to identify individual image builds. A
GUID is used as the Qshrink4 database ID.
The tool acquires Qshrink4 database files at runtime (QXDM on connect) using a set of DIAG
commands. To avoid manually identifying and side-loading the database into the tools, the
database can be retrieved at runtime using a series of Diag command/response packets. At a high
level, the process involves the following steps:
4. The tool retrieves available database IDs from the device using the File List command.
The tool queries each known processor for available database IDs using the defined set of
query commands found in this document.
5. Based on the IDs retrieved, the tool decides which databases is to be transferred from the
device.
For efficiency, it is recommended that the tool keep a local cache of previously retrieved
databases and only download new databases.
6. The tool sends a series of command packets (Open, Read, and Close commands) to retrieve
the necessary databases.