[llvm-bugs] [Bug 47939] New: bug when setting the bss segment name in a Windows build, causes it to use executable space...

[via llvm-bugs]

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

            Bug ID: 47939
           Summary: bug when setting the bss segment name in a Windows
                    build, causes it to use executable space...
           Product: libraries
           Version: 11.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: jeffr at radgametools.com
                CC: llvm-bugs at lists.llvm.org

LLVM for Windows (just like visual studio), allows you to name the segments for
compilation with the following pragmas:

#pragma code_seg("mycodename")
#pragma data_seg("mydataname")
#pragma const_seg("myconstname")
#pragma bss_seg("mybssname")

This is convenient for middleware so that our customers can track what space
our products are using.  We used this for around 20 years with the MS compiler.

LLVM handles this properly for the most part, however, if you set the BSS
segment name, if forgets that this is a BSS type segment, and then, when
linking, the executable will actually contain huge runs of zeros (rather than
just setting the segment type as zero initialized).

To test this, you should just be able to do #pragma bss_seg("test") followed by
a static char buf[1024*1024]; and see that the linked EXE is now 1 megabyte
larger.

I assume that in naming the segment, the segment type gets been lost, or that
somewhere LLVM is looking at the segment name, rather than the segment type to
decide how to create the final binary properly.

-- 
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/20201022/4b3bdff9/attachment.html>