demangle exception tracebacks #78

New Issue

sb10q · 2020-07-30T22:20:19+08:00

sb10q commented

2020-07-30 22:20:19 +08:00

currently prints e.g.

Core Device Traceback (most recent call last):
  File "dma.py", line 25, in .L_Z27artiq_run_dma.DMAPulses.runzz (RA=+0x808)
    self.core_dma.playback_handle(pulse_handle)
  File "<artiq>/coredevice/dma.py", line 114, in .L_Z44artiq.coredevice.dma.CoreDMA.playback_handleI28artiq.coredevice.dma.CoreDMAEzz (RA=+0x85c)

currently prints e.g. ```text Core Device Traceback (most recent call last): File "dma.py", line 25, in .L_Z27artiq_run_dma.DMAPulses.runzz (RA=+0x808) self.core_dma.playback_handle(pulse_handle) File "<artiq>/coredevice/dma.py", line 114, in .L_Z44artiq.coredevice.dma.CoreDMA.playback_handleI28artiq.coredevice.dma.CoreDMAEzz (RA=+0x85c) ```

astro commented

2020-08-01 03:41:08 +08:00

In ELF symbol mangling conventions private symbols are prefixed with .L.

I'm still looking for what was different with or1k. I'm not getting many symbols generated at all...

Possible ways going forward:

Modify LLVMIRGenerator to not emit private symbols
Patch binutils c++filt to demangle the prefix
Remove the prefix after symbolization in comm_kernel.py, then demangle once more

In ELF symbol mangling conventions private symbols are prefixed with `.L`. I'm still looking for what was different with or1k. I'm not getting many symbols generated at all... Possible ways going forward: - Modify LLVMIRGenerator to not emit private symbols - Patch binutils c++filt to demangle the prefix - Remove the prefix after symbolization in `comm_kernel.py`, then demangle once more

pca006132 commented

2020-08-06 15:52:40 +08:00

It seems that the .L prefix is added by the linker to indicate that is a local symbol.

diff --git a/artiq/compiler/targets.py b/artiq/compiler/targets.py
index 9b985c32..9ebc7907 100644
--- a/artiq/compiler/targets.py
+++ b/artiq/compiler/targets.py
@@ -183,6 +183,7 @@ class Target:
         """Link the relocatable objects into a shared library for this target."""
         with RunTool([self.tool_ld, "-shared", "--eh-frame-hdr"] +
                      ["{{obj{}}}".format(index) for index in range(len(objects))] +
+                     ["-x"] +
                      ["-o", "{output}"],
                      output=None,
                      **{"obj{}".format(index): obj for index, obj in enumerate(objects)}) \

By adding the -x flag, the linker would discard all local symbols, so the local symbols would not be shown in the symbol table, and the prefix would not be added.

From the --help output, it seems that or1k-linux-ld shares the same default with armv7-unknown-linux-gnueabihf-ld regarding discarding local symbols, they are both default to -X --discard-locals (Discard temporary local symbols), but I am not sure if that is a documentation problem in the or1k linker as this does not match the actual behavior...

It seems that the `.L` prefix is added by the linker to indicate that is a local symbol. ```diff diff --git a/artiq/compiler/targets.py b/artiq/compiler/targets.py index 9b985c32..9ebc7907 100644 --- a/artiq/compiler/targets.py +++ b/artiq/compiler/targets.py @@ -183,6 +183,7 @@ class Target: """Link the relocatable objects into a shared library for this target.""" with RunTool([self.tool_ld, "-shared", "--eh-frame-hdr"] + ["{{obj{}}}".format(index) for index in range(len(objects))] + + ["-x"] + ["-o", "{output}"], output=None, **{"obj{}".format(index): obj for index, obj in enumerate(objects)}) \ ``` By adding the `-x` flag, the linker would discard **all local symbols**, so the local symbols would not be shown in the symbol table, and the prefix would not be added. From the `--help` output, it seems that `or1k-linux-ld` shares the same default with `armv7-unknown-linux-gnueabihf-ld` regarding discarding local symbols, they are both default to `-X --discard-locals` (Discard temporary local symbols), but I am not sure if that is a documentation problem in the or1k linker as this does not match the actual behavior...

sb10q commented

2020-08-06 16:00:10 +08:00

Poster

It there any issue on or1k if we use -x there?

It there any issue on or1k if we use ``-x`` there?

pca006132 commented

2020-08-06 16:03:33 +08:00

No, probably that is a documentation error in armv7-unknown-linux-gnueabihf-ld.

It seems that the default is --discard-none. -X flag would already remove those symbols from the symbol table. However, it causes addr2line to find the wrong symbol... -x would just work.

Example of -X output:

Core Device Traceback (most recent call last):
  File "dma.py", line 25, in $a.2 (RA=+0x7d4)
    self.core_dma.playback_handle(pulse_handle)
  File "<artiq>/coredevice/dma.py", line 114, in __modinit__ (RA=+0x82c)
    dma_playback(now_mu(), ptr)
  File "runtime/src/kernel/dma.rs", line 196, column 18, in (Rust function)
    <unknown>

No, probably that is a documentation error in `armv7-unknown-linux-gnueabihf-ld`. It seems that the default is `--discard-none`. `-X` flag would already remove those symbols from the symbol table. However, it causes `addr2line` to find the wrong symbol... `-x` would just work. Example of `-X` output: ``` Core Device Traceback (most recent call last): File "dma.py", line 25, in $a.2 (RA=+0x7d4) self.core_dma.playback_handle(pulse_handle) File "<artiq>/coredevice/dma.py", line 114, in __modinit__ (RA=+0x82c) dma_playback(now_mu(), ptr) File "runtime/src/kernel/dma.rs", line 196, column 18, in (Rust function) <unknown> ```

pca006132 commented

2020-08-06 16:04:11 +08:00

It there any issue on or1k if we use -x there?

No. Actually, setting -x, -X or --discard-none would have no effect for or1k for whatever reason.

> It there any issue on or1k if we use ``-x`` there? No. Actually, setting `-x`, `-X` or `--discard-none` would have no effect for or1k for whatever reason.

sb10q commented

2020-08-06 16:04:37 +08:00

Poster

OK, so we can simply add -x all the time and that would fix the issue on ARM and not cause regressions on or1k. Correct?

OK, so we can simply add ``-x`` all the time and that would fix the issue on ARM and not cause regressions on or1k. Correct?

pca006132 commented

2020-08-06 16:05:45 +08:00

OK, so we can simply add -x all the time and that would fix the issue on ARM and not cause regressions on or1k. Correct?

For the simple case above that I've currently tested, no regression.

> OK, so we can simply add ``-x`` all the time and that would fix the issue on ARM and not cause regressions on or1k. Correct? For the simple case above that I've currently tested, no regression.

sb10q commented

2020-08-06 16:06:12 +08:00

Poster

OK. Please just commit the change to the ARTIQ master branch.