[llvm-bugs] [Bug 49397] New: bsymbolic test produces invalid output

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49397

            Bug ID: 49397
           Summary: bsymbolic test produces invalid output
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: wasm
          Assignee: unassignedbugs at nondot.org
          Reporter: wingo at igalia.com
                CC: llvm-bugs at lists.llvm.org, sbc at chromium.org

Consider bsymbolic.s, from lld/test/wasm:

```
.globl foo
foo:
  .functype foo () -> ()
  end_function

.globl get_foo_address
get_foo_address:
  .functype get_foo_address () -> (i32)
  global.get foo at GOT
  end_function

.globl get_bar_address
get_bar_address:
  .functype get_bar_address () -> (i32)
  global.get bar at GOT
  end_function

.globl bar
.section  .data.bar,"",@
bar:
  .int 42
.size bar, 4
```

If you test this file with llvm-lit:

```
bin/llvm-lit -a ../lld/test/wasm/bsymbolic.s
```

Then you try to validate the output file, you get an error:

```
wasm-validate tools/lld/test/wasm/Output/bsymbolic.s.tmp1.so
tools/lld/test/wasm/Output/bsymbolic.s.tmp1.so:00000c3: error: table variable
out of range: 0 (max 0)
```

Indeed there is an elem section that refers to table 0, but there is no
indirect function table in this file.

The reason for this is that no input requires the indirect function table.  The
input file bsymbolic.s.tmp.o has a couple R_WASM_GLOBAL_INDEX_LEB relocs for
foo at GOT and bar at GOT but no function pointer bitcasts (R_WASM_TABLE_INDEX_LEB). 
So the linker populates the elem section with entries for these GOT pointers
but as there is no corresponding table, it's an error.

What's the intention of this mode?  If we go to add an elemSec entry when there
is no indirect function table, should we ensure that the table is present, or
should we not emit elemSec entries?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210302/b5a2f664/attachment.html>