similar to: 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

I've prepared a preliminary patch with the intention of implementing PPC-EABI subtarget features for applications that run in a standalone embedded environment. https://reviews.llvm.org/D26344 The most significant difference compared with the SVR4 ABI is the use of SDA (small data area). This allows full-word constants and data to be grouped into small-data sections accessed using relocated

Just pinging this patch for review, particularly from PPC maintainers: https://reviews.llvm.org/D26344 It's now rebased for the latest master commits, `check-all` test results match those of the upstream base. There is also a clang driver patch, extending PPC target support for the `-G` flag: https://reviews.llvm.org/D26345 And lld patch implementing the _SDA_BASE_ symbols and includes an

----- Original Message ----- > From: "Jack Andersen via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, November 16, 2016 10:39:53 PM > Subject: Re: [llvm-dev] [MC] Target-Independent Small Data Section Handling > > Just pinging this patch for review, particularly from PPC > maintainers:

Alexander, On Darwin the "__cstring" section (really section with type S_CSTRING_LITERAL) is defined to contain zero terminate strings of bytes that the linker can merge and re-order. If you want pad bytes before and after the string, you need to put the strings in a different section (e.g. __TEXT, __const). But, CF/NSString literals will be problematic. The compiler emits a static

On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > This is a brain-dump of my thoughts on the MCStreamer interface after several > days of digging around trying to get a COFF writer working. Great! Something that is worth pointing out is that the MCStreamer API is intended to directly reflect what is happening in .s files. We basically want one MCStreamer callback to correspond to one

(forgot to CC llvmdev) On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <glider at google.com> wrote: > Hey Anna, Nick, Ted, > > We've the following problem with string literals under ASan on Mac. > Some global string constants end up being put into the .cstring > section, for which the following rules apply: > - the strings can't contain zeroes in their

On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one > statement in the .s file. This makes it easier to handle from the compiler > standpoint, but is also very important for the llvm-mc assembly parser > itself. > > This

I'm trying to build LLVM on OPENBSD current with today's svn (feb 23), and it fails to build with the following errors: llvm[2]: Compiling ELFWriter.cpp for Release build In file included from ELFWriter.cpp:51: /root/llvm/include/llvm/Target/TargetLoweringObjectFile.h:345: error: virtual outside class declaration /root/llvm/include/llvm/Target/TargetLoweringObjectFile.h:345: error:

This is a brain-dump of my thoughts on the MCStreamer interface after several days of digging around trying to get a COFF writer working. All fragments should be associated with a symbol. For assembler components, a unnammed "virtual" symbol can be used when there is no explicit label defined. Section assignment should be the responsiblity of the object imlementing the MCStreamer

hi, I am trying to build the llvm trunk with make. I am trying a debug build and I am ending with the following build error. /home/rajika/projects/llvm/llvm/lib/Target/TargetLoweringObjectFile.cpp: In member function ‘virtual bool llvm::TargetLoweringObjectFileMachO::shouldEmitUsedDirectiveFor(const llvm::GlobalValue*, llvm::Mangler*) const’:

Hi - I've attached a patch to make the assembly parser recognise the .bss directive on Darwin targets as a switch to the (__DATA,__bss) section. The ELF & COFF assembly parsers already recongnise the .bss directive. I've added a test case for it too. Thanks - Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: bss.patch Type:

LGTM On 29 September 2013 06:08, Nicholas White <n.j.white at gmail.com> wrote: > I believe it's a feature missing in MC - > https://github.com/opensource-apple/cctools/blob/4da58fd2fc026317ed9e9ef1feabf21ed0bb7a81/cctools-836/as/i386.c > line 539 adds support for the .bss directive if certain variables are > defined, and mainline gas supports it on all ARM targets: >

Just tried the latest release and found a minor bug. Have a UFD w/ SYSLINUX, which boots a simple .BSS image no problem. Launching exactly the same image on a ISOLINUX disc fails w/ the following error msg: Invalid image type for this media That's it for this msg. Later....Jet -- Powered by Outblaze

Hello LLVM-Devs, Perhaps a pedantic question, but I'm wondering how __DATA,__common and __DATA,__bss symbols differ, and whether llvm-nm ought not classify the former as type "B" as it does the latter: $ cat bss.c int i; static int si __attribute__((used)); $ clang -fno-common -c bss.c $ nm bss.o 0000000000000000 S _i 0000000000000004 b _si $ nm -m bss.o 0000000000000000

Hello, I noticed that the SPU assembly printer prints just ".bss", when gas requires ".section .bss". Now the gas prints out: Assembler messages: Error: expected symbol name Attached is a test case and a patch to fix this. (This time 'make check' passes also ;) kalle -------------- next part -------------- A non-text attachment was scrubbed... Name: spu_bss.patch

Is this an extension to what cctools' assembler provides or a missing feature in MC? On 28 September 2013 18:48, Nicholas White <n.j.white at gmail.com> wrote: > Hi - I've attached a patch to make the assembly parser recognise the > .bss directive on Darwin targets as a switch to the (__DATA,__bss) > section. The ELF & COFF assembly parsers already recongnise the .bss

I have a 2gig usb drive FAT formatted with 32K cluster I used syslinux 3.06 to create a boot sector so that I could boot Damn Small Linux, INSERT and memtest86. They are all working fine. I have a DOS bootable CD and have been following this guy's instructions... http://fuzzymunchkin.dyndns.org/tdot/usbkeyfob/index.php3 I used a WinXP floppy formatted with the 'make ms-dos bootdisc'

Thanks - how would I go about getting this committed? Nick On 30 September 2013 13:50, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > LGTM > > On 29 September 2013 06:08, Nicholas White <n.j.white at gmail.com> wrote: >> I believe it's a feature missing in MC - >>

I believe it's a feature missing in MC - https://github.com/opensource-apple/cctools/blob/4da58fd2fc026317ed9e9ef1feabf21ed0bb7a81/cctools-836/as/i386.c line 539 adds support for the .bss directive if certain variables are defined, and mainline gas supports it on all ARM targets: https://sourceware.org/binutils/docs/as/ARM-Directives.html . Supporting the directive on all Darwin targets could