[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug gas/31396] New: Symbols referenced from ".if"/"==" end up in the sy
From: |
palmer at gcc dot gnu.org |
Subject: |
[Bug gas/31396] New: Symbols referenced from ".if"/"==" end up in the symbol table |
Date: |
Sat, 17 Feb 2024 02:54:17 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=31396
Bug ID: 31396
Summary: Symbols referenced from ".if"/"==" end up in the
symbol table
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: palmer at gcc dot gnu.org
Target Milestone: ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug gas/31396] New: Symbols referenced from ".if"/"==" end up in the symbol table,
palmer at gcc dot gnu.org <=