Bug 31396 - Symbols referenced from ".if"/"==" end up in the symbol table
Summary: Symbols referenced from ".if"/"==" end up in the symbol table
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: gas (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-17 02:54 UTC by Palmer Dabbelt
Modified: 2024-02-17 09:52 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Palmer Dabbelt 2024-02-17 02:54:17 UTC
Nathan and I were playing around with some odd behavior in dav1d and I've managed to reduce the test case down to something small.  I'm just not actually sure the behavior is a bug.  We were looking at the RISC-V port, but the behavior seems the same on x86 as well:

$ cat test.s
.text

.if undefined == 0
.endif

.global main
main:
$ gcc test.s -o test.o -c
$ objdump -dt test.o

test.o:     file format elf64-x86-64

SYMBOL TABLE:
0000000000000000         *UND*	0000000000000000 undefined
0000000000000000 g       .text	0000000000000000 main

The resulting objects link fine, I guess because nothing is actually trying to resolve a reference to the undefined symbol.  It just seems a little odd to have something unreferenced and undefined end up in the symbol table.

I haven't really spent much time touching these more generic bits of GAS and just grepping for "==" is pretty useless, thus I'm a bit lost here.  As far as I can tell this isn't actually causing any adverse effects, but I figured I'd at least file something in case anyone else is interested.
Comment 1 Andreas Schwab 2024-02-17 09:52:24 UTC
There is nothing special about .if or '=='.  The expression evaluator will enter any identifier into the symbol table that is part of an expression, see symbol_find_or_make.