From: Andrew Reusch <areusch@octoml.ai>
Date: Thu, 14 May 2020 20:33:43 +0000 (-0700)
Subject: Overestimate binary size for microTVM compiled binaries. (#5590)
X-Git-Tag: upstream/0.7.0~724
X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=8b8fba98aaecbee983fa5586380b1e5baf99ea6e;p=platform%2Fupstream%2Ftvm.git

Overestimate binary size for microTVM compiled binaries. (#5590)

* Overestimate binary size for microTVM compiled binaries.

 * Currently uTVM binary section sizes are computed by summing the
   sizes of all symbols in the section.
 * This method produces errors because it presumes the linker works in
   a particular way, rather than analyzing the linked output.
 * As we intend to move away from linking inside TVM (RFC
   forthcoming), just using this stopgap to make forward progress
   until then.

* address weberlo comments

* fix regression (use 64 bit word size)
---

diff --git a/python/tvm/contrib/binutil.py b/python/tvm/contrib/binutil.py
index 21e06df..d784b7b 100644
--- a/python/tvm/contrib/binutil.py
+++ b/python/tvm/contrib/binutil.py
@@ -147,25 +147,15 @@ def tvm_callback_get_section_size(binary_path, section_name, toolchain_prefix):
                 section_size += entry_size
                 break
 
-    # NOTE: For some reason, the size of the BSS section on the RISC-V
-    # GCC is sometimes reported to be smaller than it is, so we need to adjust
-    # for this.
-    if "riscv" in toolchain_prefix and section_name == "bss":
-        # TODO(weberlo): Figure out why 32 is the minimum constant that works.
-        #
-        # The current hypothesis is that the last symbols in the ".bss" and
-        # ".sbss" sections may have size zero, since the symbols in these
-        # sections are uninitialized and there's no address that follows that
-        # would enforce a particular size.
-        #
-        # If this is the case, then 32 just happens to be a safe amount of
-        # padding for most cases, but symbols can be arbitrarily large, so this
-        # isn't bulletproof.
-        return section_size + 32
-
     # NOTE: in the past, section_size has been wrong on x86. it may be
     # inconsistent. TODO: maybe stop relying on `*size` to give us the size and
     # instead read the section with `*objcopy` and count the bytes.
+    # NOTE(areusch): I think the problem is due to alignment ops in the linker.
+    # Since this is going away in the impending switch to on-device runtime,
+    # add a constant to hopefully absorb these relocations.
+    if section_size > 0:
+        section_size += 64
+
     return section_size