dbghelp: Fix the spelling of a couple of comments.

This commit is contained in:
Francois Gouget 2022-10-20 16:23:05 +02:00 committed by Alexandre Julliard
parent 5f0b7390e9
commit 0eb40cdbd0
2 changed files with 4 additions and 4 deletions

View file

@ -271,11 +271,11 @@ struct symt_data
* address in one of its ranges
*
* Notes:
* (A): shall evolve but storage is native is awkward: from PGO testing, the
* (A): shall evolve but storage in native is awkward: from PGO testing, the
* top function is stored with its first range of address; all the others
* are stored as blocks, children of compiland, but which lexical parent
* is the top function. This breaks the natural assumption that
* children <> lexical parent is symetrical.
* children <> lexical parent is symmetrical.
* (B): see dwarf.c for some gory discrepancies between native & builtin
* DbgHelp.
*/

View file

@ -2201,7 +2201,7 @@ static void dwarf2_parse_subprogram_block(dwarf2_subprogram_t* subpgm,
}
/* Dwarf tends to keep the structure of the C/C++ program, and emits DW_TAG_lexical_block
* for every block in source program.
* for every block the in source program.
* With inlining and other optimizations, code for a block no longer lies in a contiguous
* chunk of memory. It's hence described with (potentially) multiple chunks of memory.
* Then each variable of each block is attached to its block. (A)
@ -2217,7 +2217,7 @@ static void dwarf2_parse_subprogram_block(dwarf2_subprogram_t* subpgm,
*
* DbgHelp only exposes a contiguous chunk of memory for a block.
*
* => Store internaly all the ranges of addresses in a block, but only expose the size
* => Store internally all the ranges of addresses in a block, but only expose the size
* of the first chunk of memory.
* Otherwise, it would break the rule: blocks' chunks don't overlap.
* Note: This could mislead some programs using the blocks' address and size information.