0
0
mirror of https://github.com/netwide-assembler/nasm.git synced 2025-07-24 10:25:42 -04:00

parser: when flattening an eop, must preserve any data buffer

An eop may have a data buffer associated with it as part of the same
memory allocation. Therefore, we need to move "subexpr" up instead of
merging it into "eop".

This *partially* resolves BR 3392707, but that test case still
triggers a violation when using -gcv8.

Reported-by: Suhwan <prada960808@gmail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
This commit is contained in:
H. Peter Anvin (Intel) 2020-07-30 15:46:12 -07:00
parent 0e6e013813
commit 6ac6ac57e3
2 changed files with 32 additions and 5 deletions

View File

@ -458,11 +458,17 @@ static int parse_eops(extop **result, bool critical, int elem)
/* Subexpression is empty */
eop->type = EOT_NOTHING;
} else if (!subexpr->next) {
/* Subexpression is a single element, flatten */
eop->val = subexpr->val;
eop->type = subexpr->type;
eop->dup *= subexpr->dup;
nasm_free(subexpr);
/*
* Subexpression is a single element, flatten.
* Note that if subexpr has an allocated buffer associated
* with it, freeing it would free the buffer, too, so
* we need to move subexpr up, not eop down.
*/
if (!subexpr->elem)
subexpr->elem = eop->elem;
subexpr->dup *= eop->dup;
nasm_free(eop);
eop = subexpr;
} else {
eop->type = EOT_EXTOP;
}

21
test/br3392707.asm Normal file
View File

@ -0,0 +1,21 @@
bits 32
db 33
db (44)
; db (44,55) -- error
db %(44.55)
db %('XX','YY')
db ('AA')
db %('BB')
db ?
db 6 dup (33)
db 6 dup (33, 34)
db 6 dup (33, 34), 35
db 7 dup (99)
db 7 dup (?,?)
dw byte (?,44)
dw 0xcc, 4 dup byte ('PQR'), ?, 0xabcd
dd 16 dup (0xaaaa, ?, 0xbbbbbb)
dd 64 dup (?)