Skip to content
Back to skills

Spt Binary Analysis

ASecurity

Analyze SPT3.8 ELF binaries using objdump-spt. Identifies section layout, per-function code size contributors, and diagnoses oversized SPT images. Use when the user asks "why is my SPT image so large", "which SPT function is biggest", or "why did my SPT ELF grow".

  • 5 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added October 15, 2026
developmentgoc++rails

Works with

  • mcp

Security analysis

A100/100

Scanned October 15, 2026

npx -y skills add nxp-agentic-ai/s32-ds-ai-support --skill spt-binary-analysis --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Spt Binary Analysis?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Spt Binary Analysis
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/nxp-agentic-ai-spt-binary-analysis/badge)](https://www.skillsdirectory.com/skills/nxp-agentic-ai-spt-binary-analysis)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: spt-binary-analysis
description: >
  Analyze SPT3.8 ELF binaries using objdump-spt. Identifies section layout,
  per-function code size contributors, and diagnoses oversized SPT images.
  Use when the user asks "why is my SPT image so large", "which SPT function is
  biggest", or "why did my SPT ELF grow".
license: LA_OPT_Online Code Hosting NXP_Software_License
metadata:
  author: NXP
  version: "1.0.0"
  product: compiler
  tags: '[spt, spt3.8, objdump-spt, binary, elf, size, analysis, radar, s32r, embedded]'
---

# SPT3.8 Binary Analysis (NXP SPT / Radar Signal Processing Toolbox)

Analyze a SPT3.8 ELF binary to determine what contributes to code size on the SPT
accelerator, which functions dominate the image, and how sections are structured.
Uses `objdump-spt` -- the only binary analysis tool available in the SPT3.8 toolchain.

## When to use

Use this skill when:
- User asks "why is my SPT image so large?"
- User asks "which SPT function is the biggest?"
- User asks "why did my SPT ELF grow after this change?"

Do **not** use this skill for:
- Per-instruction encoding -> use `spt-assembler-explorer`

## Available Capabilities

| Type | Name | Invocation |
|------|------|------------|
This skill uses the standardized `search_actions` + `execute_action` MCP tool surface.

| Action name | Purpose |
|------|------|
| `compiler.list_spt_tools` | Discover toolchain; call first |
| `compiler.spt_execute` | Run `objdump-spt` |

Note: SPT3.8 does **not** ship `size-spt`, `nm-spt`, or `readelf-spt`.
`objdump-spt` is the only binary inspection tool available.

## Quickstart

### 1. Discover toolchain

```
Tool:   list_spt_compiler_tools  ->  toolchain_bin_dir
```

### 2. Disassemble to enumerate sections and symbols

```
Tool:    spt_execute, binary="objdump-spt", args="-Dr image.elf"
Output:  section headers and per-symbol instruction listings
```

### 3. Rank functions by instruction count

Count instruction lines per labeled symbol block in the disassembly output.
Each SPT instruction is 16 bytes (128 bits); divide byte size by 16 for instruction count.

## Configuration

Key facts:
- Must use `objdump-spt`; stock GNU `objdump` does not decode SPT mnemonics
- No C/C++ compiler; every byte in `.text` came from `.spt` assembly source
- Every SPT instruction is 16 bytes (128 bits)

## Guardrails

**Scope**
- Only calls `list_spt_compiler_tools` and `spt_execute`. No user files modified.

**Destructive actions**
- Read-only analysis of the provided ELF.

**Refuse-and-escalate**
- If no SPT3.8 toolchain found, stop and tell the user.
- Do not use stock GNU `objdump`, `nm`, or `size` on SPT ELFs.
- Do not attempt to call `size-spt`, `nm-spt`, or `readelf-spt` -- they do not exist.

**Resource limits**
- Do not run full disassembly on very large ELFs without user confirmation.

**Secrets**
- Do not expose sensitive content from data sections.

## Workflow

### Step 1 -- Discover toolchain
Call `list_spt_compiler_tools()` and confirm `objdump-spt` is present.

### Step 2 -- Disassemble ELF

```jsonc
{
  "toolchain_bin_dir": "<bin dir>",
  "binary": "objdump-spt",
  "args": "-Dr image.elf"
}
```

Each labeled block in the output (e.g. `<function_name>:`) is one function.
Count instruction lines per block to rank contributors by size.

### Step 3 -- Rank functions by size
Sort labeled blocks descending by instruction count. Focus on:
- Largest user functions and what they do
- Repeated `copy.*` sequences or unrolled FFT stages that could use `loop`
- Large absolute-address symbol chains

### Step 4 -- Inspect section layout (optional)

```jsonc
{
  "binary": "objdump-spt",
  "args": "-h image.elf"
}
```

Check that sections are placed in the expected SPT memories:
- `.text` -> PMEM (program memory)
- `.rodata` -> TRAM (twiddle tables, FIR taps)
- `.data` / `.bss` -> OPRAM (operand buffers)

### Common SPT size patterns

| Symptom | Cause | Fix |
|---------|-------|-----|
| Very large `.text` for small algorithm | Fully unrolled FFT/FIR | Convert to `loop` + indirect variant |
| Repeated `copy.simple` | Per-slice explicit copies | Use one wider `copy.simple` with proper `vec_sz` |
| Constants in `.data` | Missing `.section .rodata` | Move to `.rodata` / TRAM |
| Redundant `set #imm, WR_x` blocks | Per-call context reload | Factor into shared setup label |

## Validation loop

1. `list_spt_compiler_tools()` returns a non-empty toolchain list.
2. `objdump-spt -Dr image.elf` produces a disassembly listing.
3. Each large symbol block is explained with root cause and actionable recommendation.

## Out of scope

- Per-instruction encoding (use `spt-assembler-explorer`)
- Linking / section placement analysis -- SPT3.8 has no linker tool in the MCP toolchain

## See Also

- `spt-assembler-explorer` -- per-instruction encoding and assembly examples

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.