The C grammar already exposes a struct/union member's bitfield width as a
"bitfield_clause" node and the parser already recognized "int a : 4;", but
it threw the width away (the member was stored with size 0 and a FIXME). As
a result "tc" rendered the member as a plain "int a;", "ts" produced a
full-int "pf" format ("pf d4d4d4 a b c") and "tp" mis-read every field as a
whole integer.
RzTypeStructMember and RzTypeUnionMember already carry a "size" field
documented as "in bits"; it is now used as the bitfield width, where 0 means
the member is not a bitfield:
- The struct and union member parsers store the parsed bit width on the
member instead of discarding it.
- The pretty printer emits " : <width>" before the member's trailing ';',
so "tc"/"tcd" round-trip "struct qwe { int a : 4; int b : 16; int c : 3; }".
- rz_base_type_as_format() (used by "ts"/"tp") now emits the pf packed-bits
spec ":N" for a bitfield member, with the bit order matching the target
endianness ("<" little-endian / ">" big-endian), instead of the member
type's full format. "ts qwe" becomes 'pf ":4<:16<:3< a b c"' and "tp"
unpacks the fields correctly (a=5, b=0x1234, c=0 for 0x00012345 on x86).
Serialization keeps the width in the 3rd comma-field of the existing
"struct.<name>.<member>" / "union.<name>.<member>" value, i.e.
"type,offset,bitsize". That field was already written (always as 0) and
ignored on load, so the on-disk layout is unchanged and only its meaning is
now honored. The project version is bumped to 24 with an additive no-op
migration: an absent or 0 bitsize deserializes as a regular, non-bitfield
member.
Tests: a unit test parses a bitfield struct and union and checks the member
widths, the rendered string and the "pf" format; a db/cmd/types test covers
the full "td"/"tcd"/"ts"/"tp" flow; a project-migration test with a new
v23-bitfield.rzdb fixture covers v23->v24, and the "migrate info" db test is
updated for the new version.
The PDB type parser (librz/arch/pdb_process.c) still drops bitfield members
because their LF_BITFIELD member type resolves to NULL; wiring LF_BITFIELD up
to the new member "size" field, with tests in test/unit/test_pdb.c, is left
as a follow-up.
Co-authored-by: Anton Kochkov <anton.kochkov@gmail.com>
C23 lets an enum fix its underlying type, e.g. "enum E : long long { ... }".
The C grammar already exposes it as the "underlying_type" field of an
enum_specifier, and RzBaseType already has a "type" slot documented as
used by enums, but the parser ignored the field and always left it NULL.
- parse_enum_node() now reads the "underlying_type" field and stores the
parsed type on RzBaseType::type (reusing parse_type_node_single(), so
primitive, sized and typedef'd integer types are all handled). Classic
enums keep a NULL underlying type.
- The pretty printer emits " : <type>" between the enum name and its body
when an underlying type is present, so "tc"/"tcd"/"tec" round-trip it.
- enum_bitsize() now derives the width from the underlying type instead of
the hardcoded 32-bit default (resolving the long-standing FIXME); it
still falls back to 32 for a classic enum.
Single-token underlying types (int, uint64_t, char, ...) work end-to-end
with the bundled grammar revision: the existing "enhanced enum" db test is
updated to round-trip "enum v : int" and a unit test covers
"enum EU : uint64_t". Multi-word underlying types (long long, unsigned int)
are added as BROKEN db tests; the bundled grammar parses them to an ERROR
node and drops the underlying type, so these tests fail for now and will
pass once rizin-grammar-c accepts sized type specifiers as the enum
underlying type. No further rizin change is needed for that step.
Co-authored-by: Anton Kochkov <anton.kochkov@gmail.com>
This commit changes several settings. The main reason is to have them
contained in one search group, and not spread over the search and string group.
This becomes important with the search refactor, since the search is now also
more contained in a single module and can make use of the more settings.
- Remove str.search.max_uni_blocks - Effectively a metric the user should not know about; adds too much complexity. Also not documented.
- str.search.encoding -> str.encoding - Valid for all string interpretations.
- str.search.max_threads -> search.max_threads - This is a general setting for the search now.
- str.search.raw_alignment -> search.str.raw_alignment - Unify settings (only used for RzBin search.).
- str.search.min_length -> search.str.min_length - Unify settings.
- str.search.buffer_size -> search.str.max_length - Unify settings.
- str.search.max_region_size -> search.str.max_region_size - Unify settings.
- str.search.check_ascii_freq -> search.str.check_ascii_freq - Unify settings.
Part 3/9. Likely won't build in between parts.
Co-authored-by: wargio <deroad@kumo.xn--q9jyb4c>
The only place where this field was set to a non-zero value was the now
removed fb command, and it was never used for anything sensible. Thus it
is safe to remove.
Unlike rz_vector_index_ptr, which is very important, there do not seem
to be any valid usages of rz_pvector_index_ptr in rizin, cutter or
rz-ghidra that could not be replaced by rz_pvector_at.
In case there will be a use-case for it in the future, it can also be
done by rz_pvector_data(...) + i.
- `RZ_PROJECT_VERSION` 14
- Add `RzCallable`.has_unspecified_parameters
- Add `RzAnalysis`.debug_info
- Add `RzAnalysisVarStorageType` composite and `eval` `pending`
- Support for parse DWARF section "debug_loclists", "debug_ranges", "debug_rnglists"
- Partial support for eval DWARF expr_loc
- Support for anonymous Type, function variable, struct member
- Cache all DWARF information in `RzAnalysisDebugInfo` and remove `SDB` based caching.
- Add arm32, arm64, TriCore DWARF register name
- Fix same name basetype
Variables on the stack are not identified by bp/sp+<offset> anymore, but
by their address from the bottom of the stack frame (RzStackAddr),
independent of how they are accessed.
So now there are only two kinds of variables: stack and register.
This required some major refactoring and other changes:
* RzAnalysisVar.isarg was removed. Whether a variable is an argument is
now specified implicitly by its storage location.
* Varsub of struct fields had to be rewritten so fields can be queried
by arbitrary stack addresses using the recently introduced sp
tracking, as the old approach to fill a list with all fields would not
work anymore.
* analysis.vars.stackname was removed, new behavior is more similar to
this being true before.
* Variables will not be created at stack+0 now, because the return
address is there. Before, vars were only created sometimes in such
cases.
* Variables created from bp offsets in x86 are not deleted anymore if
the function's bp_frame is false (see removed
rz_analysis_function_delete_vars_by_kind(fcn,
RZ_ANALYSIS_VAR_KIND_BPV); calls). This may lead to some
false-positive detected variables. Whether this really is a practical
issue is yet to be seen. At least there are no meaningful tests that
are broken by this.
* Applying variables from dwarf needed some fixes for determining the
correct stack locations of variables in order to write meaningful
tests. The handling is still not entirely correct for all
possibilities of dwarf info, but at least the changed/added test cases
are right and serve as a reference for future changes.
* Projects version 11 is introduced.
* afvb commands have been removed, afvs now handles all stack vars.
The stack pointer was previously already tracked during analysis for
variables and their accesses, but not stored in any sensible form for
further use. RzAnalysisBlock.stackptr and parent_stackptr were used in
some places, but they had no evident meaning.
Now we store the sp at the entry of a basic block and the difference
from that for every instruction inside the block to allow for efficient
querying of the sp value at arbitrary analyzed addresses.
RzAnalysisFunction.stackptr is now deprecated as its previous use was
primarily as a temporary accumulator, which is now handled locally, but
full removal of it would go beyond the scope here.
asm.stackptr visualizes both the absolute sp value and the delta of each
instruction in disassembly.
Changes in librz/analysis/p fix some test cases with the new tracking.
Introduces project version v10 with sp_entry/sp_delta instead of
stackptr/parent_stackptr.
Even though many of the migrations were trivial, for all previous
versions X it is important to have both tests for X->X+1 migrations
and loading X in current rizin.
See leading comment in test_project_migrate.c for details.
Leaks detected by these tests were also fixed.
- Introduce the following new methods:
* `rz_analysis_similarity_basic_block()`
* `rz_analysis_similarity_function()`
* `rz_analysis_similarity_basic_block_2()`
* `rz_analysis_similarity_function_2()`
* `rz_analysis_match_basic_blocks()`
* `rz_analysis_match_functions()`
* `rz_analysis_match_basic_blocks_2()`
* `rz_analysis_match_functions_2()`
- Remove `RzAnalysisDiff` and its usages
- Remove `librz/analysis/diff.c` entirely to and adds `librz/analysis/similarity.c`
- Remove a lot of unused structures and simplified the code by a lot
- Fix typo in levenshtein
- Remove `librz/core/gdiff.c` and `gdiff` functions since they were unused or only used in rz-diff
- Remove `difftype` (or "color") from `RzANode` which lead to dead code
- Decrease serialized data in projects.
- Add `RzAnalysisVarKind` and `RzAnalysisVarType` and replaces all the hardcoded values
- Remove command `agd`
- Remove all `rz_core_gdiff` usages from `rz_core.h`
- Refactor `rz_analysis_var_list` and `rz_analysis_var_count` due unused argument (`RzAnalysis` was not used)
- Add new method `rz_analysis_var_count_total` to simplify some usages
- Remove `rz_core_graph_diff`
- Add `typedef RzAnalysisFcnType` on `enum``used for function types
- Remove unused `RZ_ANALYSIS_FCN_VARKIND_LOCAL`
- Remove from `RzAnalysisFunction` the following variables:
* `fingerprint`
* `fingerprint_size`
* `diff`
* `diff_ops`
* `diff_thbb`
* `diff_thfcn`
- Remove from `RzAnalysisBlock` the following variables:
* `fingerprint`
* `diff`
- Remove `RZ_ANALYSIS_THRESHOLDBB` and `RZ_ANALYSIS_THRESHOLDFCN`
- Remove the following callbacks from `RzAnalysisPlugin`
* `RzAnalysisDiffBBCallback`
* `RzAnalysisDiffFcnCallback`
* `RzAnalysisDiffEvalCallback`
- Fix fancy table columns/rows when a color string is in a cell
- Bumped project version to 9
