Andrew Kelley via llvm-dev
2017-Apr-23 17:10 UTC
[llvm-dev] why do undefined globals end up in .data instead of .bss?
Here is a module: @vals = internal unnamed_addr global [20000000 x i32] undef, align 4 When I compile it into an .o file: $ clang -c test.ll $ objdump -t test.o test.o: file format elf64-x86-64 SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 test.ll 0000000000000000 l O .data 0000000004c4b400 vals LLVM puts the global in the .data section, and results in a 77MB .o file of mostly zeroes. Why does this variable not go in the .bss section? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170423/db0314d5/attachment.html>
Friedman, Eli via llvm-dev
2017-Apr-24 18:53 UTC
[llvm-dev] why do undefined globals end up in .data instead of .bss?
On 4/23/2017 10:10 AM, Andrew Kelley via llvm-dev wrote:> Here is a module: > > @vals = internal unnamed_addr global [20000000 x i32] undef, align 4 > > LLVM puts the global in the .data section, and results in a 77MB .o > file of mostly zeroes. Why does this variable not go in the .bss section? >I think it's just an oversight; it doesn't matter for clang because it never emits globals like that. See TargetLoweringObjectFile::getKindForGlobal for the relevant logic. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Andrew Kelley via llvm-dev
2017-Apr-24 18:55 UTC
[llvm-dev] why do undefined globals end up in .data instead of .bss?
On Mon, Apr 24, 2017 at 2:53 PM, Friedman, Eli <efriedma at codeaurora.org> wrote:> On 4/23/2017 10:10 AM, Andrew Kelley via llvm-dev wrote: > >> Here is a module: >> >> @vals = internal unnamed_addr global [20000000 x i32] undef, align 4 >> >> LLVM puts the global in the .data section, and results in a 77MB .o file >> of mostly zeroes. Why does this variable not go in the .bss section? >> >> > I think it's just an oversight; it doesn't matter for clang because it > never emits globals like that. See TargetLoweringObjectFile::getKindForGlobal > for the relevant logic.I see, thanks. Would a patch be welcome which changed this behavior? Or I suppose I could emit zeroinitializer instead of undef. But it seems like undef is the more correct value. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170424/e64f3701/attachment.html>
Seemingly Similar Threads
- why do undefined globals end up in .data instead of .bss?
- [MC] Target-Independent Small Data Section Handling
- [MC] Target-Independent Small Data Section Handling
- [MC] Target-Independent Small Data Section Handling
- [LLVMdev] (Not) instrumenting global string literals that end up in .cstrings on Mac