https://sourceware.org/bugzilla/show_bug.cgi?id=22553
--- Comment #3 from john at buu dot ac.th --- This generates .lbss and .ldata - I'll try and find the code that generated .lrodata and send that in a different email. /* $gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v \ --with-pkgversion='Ubuntu 7.2.0-8ubuntu3' \ --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs \ --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ \ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 \ --program-prefix=x86_64-linux-gnu- --enable-shared \ --enable-linker-build-id --libexecdir=/usr/lib \ --without-included-gettext --enable-threads=posix \ --libdir=/usr/lib --enable-nls --with-sysroot=/ \ --enable-clocale=gnu --enable-libstdcxx-debug \ --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new \ --enable-gnu-unique-object --disable-vtable-verify \ --enable-libmpx --enable-plugin --enable-default-pie \ --with-system-zlib --with-target-system-zlib \ --enable-objc-gc=auto --enable-multiarch --disable-werror \ --with-arch-32=i686 --with-abi=m64 \ --with-multilib-list=m32,m64,mx32 --enable-multilib \ --with-tune=generic --enable-offload-targets=nvptx-none \ --without-cuda-driver --enable-checking=release \ --build=x86_64-linux-gnu --host=x86_64-linux-gnu \ --target=x86_64-linux-gnu Thread model: posix gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3) $gcc -O0 -mcmodel=medium -S ouch.c -o ouch.s */ #include <stdlib.h> #define THECOUNT 79999 extern unsigned long int curslot; extern char *bigarray[THECOUNT]; extern unsigned long int curslot3; extern char *bigarray3[THECOUNT]; unsigned long int mryo(const char *s); unsigned long int curslot=0UL; char *bigarray[THECOUNT]; static unsigned long int curslot2=0UL; static char *bigarray2[THECOUNT]; unsigned long int curslot3=0UL; char *bigarray3[THECOUNT]={"Hi",}; unsigned long int mryo(const char *s) { unsigned long int len; char *t=(char *)s, *u, *v, *w; if (!t) return 0UL; while (*t++) ; len=t-s; t=(char *)s; bigarray[curslot]=(char *)malloc(sizeof(char)*len); bigarray2[curslot2]=(char *)malloc(sizeof(char)*len); u=bigarray[curslot]; v=bigarray2[curslot2]; w=bigarray3[curslot3]; while ((*u++=*t)) { *v++=*t; *w++=*t++; } ++curslot; ++curslot2; ++curslot3; return len; } /* .file "ouch.c" .globl curslot .bss .align 8 .type curslot, @object .size curslot, 8 curslot: .zero 8 .section .lbss,"aw",@nobits .largecomm bigarray,639992,32 .local curslot2 .comm curslot2,8,8 .local bigarray2 .comm bigarray2,639992,32 .globl curslot3 .bss .align 8 .type curslot3, @object .size curslot3, 8 curslot3: .zero 8 .globl bigarray3 .section .rodata .LC0: .string "Hi" .section .ldata.rel.local,"aw",@progbits .align 32 .type bigarray3, @object .size bigarray3, 639992 bigarray3: .quad .LC0 .zero 639984 .text .globl mryo .type mryo, @function mryo: .LFB5: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 pushq %r12 pushq %rbx subq $64, %rsp .cfi_offset 12, -24 .cfi_offset 3, -32 leaq _GLOBAL_OFFSET_TABLE_(%rip), %rbx movq %rdi, -72(%rbp) movq -72(%rbp), %rax movq %rax, -56(%rbp) cmpq $0, -56(%rbp) jne .L7 movl $0, %eax jmp .L3 .L7: nop .L4: movq -56(%rbp), %rax leaq 1(%rax), %rdx movq %rdx, -56(%rbp) movzbl (%rax), %eax testb %al, %al jne .L4 movq -56(%rbp), %rdx movq -72(%rbp), %rax subq %rax, %rdx movq %rdx, %rax movq %rax, -24(%rbp) movq -72(%rbp), %rax movq %rax, -56(%rbp) movq curslot(%rip), %r12 movq -24(%rbp), %rax movq %rax, %rdi call malloc@PLT movq %rax, %rdx movabsq $bigarray@GOTOFF, %rax addq %rbx, %rax movq %rdx, (%rax,%r12,8) movq curslot2(%rip), %r12 movq -24(%rbp), %rax movq %rax, %rdi call malloc@PLT movq %rax, %rdx movabsq $bigarray2@GOTOFF, %rax addq %rbx, %rax movq %rdx, (%rax,%r12,8) movq curslot(%rip), %rax movabsq $bigarray@GOTOFF, %rdx addq %rbx, %rdx movq (%rdx,%rax,8), %rax movq %rax, -48(%rbp) movq curslot2(%rip), %rax movabsq $bigarray2@GOTOFF, %rdx addq %rbx, %rdx movq (%rdx,%rax,8), %rax movq %rax, -40(%rbp) movq curslot3(%rip), %rax movabsq $bigarray3@GOTOFF, %rdx addq %rbx, %rdx movq (%rdx,%rax,8), %rax movq %rax, -32(%rbp) jmp .L5 .L6: movq -40(%rbp), %rax leaq 1(%rax), %rdx movq %rdx, -40(%rbp) movq -56(%rbp), %rdx movzbl (%rdx), %edx movb %dl, (%rax) movq -56(%rbp), %rdx leaq 1(%rdx), %rax movq %rax, -56(%rbp) movq -32(%rbp), %rax leaq 1(%rax), %rcx movq %rcx, -32(%rbp) movzbl (%rdx), %edx movb %dl, (%rax) .L5: movq -48(%rbp), %rax leaq 1(%rax), %rdx movq %rdx, -48(%rbp) movq -56(%rbp), %rdx movzbl (%rdx), %edx movb %dl, (%rax) movzbl (%rax), %eax testb %al, %al jne .L6 movq curslot(%rip), %rax addq $1, %rax movq %rax, curslot(%rip) movq curslot2(%rip), %rax addq $1, %rax movq %rax, curslot2(%rip) movq curslot3(%rip), %rax addq $1, %rax movq %rax, curslot3(%rip) movq -24(%rbp), %rax .L3: addq $64, %rsp popq %rbx popq %r12 popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE5: .size mryo, .-mryo .ident "GCC: (Ubuntu 7.2.0-8ubuntu3) 7.2.0" .section .note.GNU-stack,"",@progbits */ ________________________________________ From: nickc at redhat dot com [sourceware-bugzi...@sourceware.org] Sent: Thursday, January 4, 2018 10:33 PM To: John Gatewood Ham Subject: [Bug gas/22553] .largecomm, .lbss, .ldata, and .lrodata are still not documented after many, many years https://sourceware.org/bugzilla/show_bug.cgi?id=22553 Nick Clifton <nickc at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2018-01-04 CC| |nickc at redhat dot com Ever confirmed|0 |1 --- Comment #2 from Nick Clifton <nickc at redhat dot com> --- Hi John, I have posted a potential patch here: https://sourceware.org/ml/binutils/2018-01/msg00027.html This only addresses the .largecomm pseudo-op however. I am not sure that .ldata, .lbss, .lrodata are actual assembler pseudo-ops. They are section names, so they can appear in assembler output from the compiler as part of a ".section ..." directive. But they should not appear on their own as directives. Can you provide an example of how gcc generates them ? Cheers Nick -- You are receiving this mail because: You reported the bug. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils