search for: __data

...rr) + count = 0; + + *var = new_var; + + return count; +} + +#define SHOW_FUNCTION2(__FUNC, __VAR, __CONV) \ +static ssize_t __FUNC(elevator_t *e, char *page) \ +{ \ + struct cfq_data *cfqd = e->elevator_data; \ + struct cfq_driver_data *cfqdd = cfqd->cfqdd; \ + unsigned int __data = __VAR; \ + if (__CONV) \ + __data = jiffies_to_msecs(__data); \ + return cfq_cgroup_var_show2(__data, (page)); \ +} +SHOW_FUNCTION2(cfq_cgroup_slice_cgroup_show, cfqdd->cfq_cgroup_slice, 1); +#undef SHOW_FUNCTION2 + +#define STORE_FUNCTION2(__FUNC, __PTR, MIN, MAX, __CONV) \ +s...

...573..40a734b 100644 --- a/purgatory/arch/i386/console-x86.c +++ b/purgatory/arch/i386/console-x86.c @@ -55,9 +55,9 @@ static void putchar_vga(int ch) */ /* Base Address */ -uint8_t console_serial = 0; -uint16_t serial_base = 0x3f8; /* TTYS0 */ -uint32_t serial_baud = 0; +uint8_t console_serial __data = 0; +uint16_t serial_base __data = 0x3f8; /* TTYS0 */ +uint32_t serial_baud __data = 0; #define XMTRDY 0x20 diff --git a/purgatory/arch/i386/crashdump_backup.c b/purgatory/arch/i386/crashdump_backup.c index 365eb5d..0438a75 100644 --- a/purgatory/arch/i386/crashdump_backup.c +++ b/pu...

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 000...

Hi all, Right now the Mangler::getValueName() method will produce something like "__unnamed_1_37" for a global value that doesn't have a name. This is wrong for Objective-C where CFStrings will get these labels, thus preventing the linker from coalescing them. [/tmp]> nm -s __DATA __cfstring -m foo.o 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 ... I think that prepending the PrivateGlobalPrefix to these names would be the way to go. My question is whether getValueName() should do the pre...

...In MachO do you just put these into the .bss section? > Macho has a special zerofill directive (targeted at the BSS section) for this. You can see this by running your example like this: $ llc t.ll -o - -mtriple=i386-apple-darwin10 .section __TEXT,__text,regular,pure_instructions .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 .section __DATA,__data _tst2: ## @tst2 .ascii "\000\001\002\003" -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100507/90...

...ug_pubnames): 168873 | Section (__DWARF, __debug_pubnames): 165104 Section (__DWARF, __debug_pubtypes): 32449 | Section (__DWARF, __debug_str): 17541 | Section (__DWARF, __debug_str): 0 Section (__DWARF, __debug_ranges): 456 | Section (__DWARF, __debug_ranges): 0 Section (__DATA, __const): 100 | Section (__DATA, __const): 136 Section (__TEXT, __cstring): 11543 | Section (__TEXT, __cstring): 12678 Section (__DATA, __data): 64 | Section (__DATA, __data): 76 Section (__DATA, __const_coal): 48 | Section (__TEXT, __const_coal): 128 | Section (__D...

...to the .bss section? >> > > Macho has a special zerofill directive (targeted at the BSS section) for this. You can see this by running your example like this: > > $ llc t.ll -o - -mtriple=i386-apple-darwin10 > .section __TEXT,__text,regular,pure_instructions > .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 > .section __DATA,__data > _tst2: ## @tst2 > .ascii "\000\001\002\003" > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to deal with dllexports...

...into the .bss section? > > > Macho has a special zerofill directive (targeted at the BSS section) for > this. You can see this by running your example like this: > > $ llc t.ll -o - -mtriple=i386-apple-darwin10 > .section __TEXT,__text,regular,pure_instructions > .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 > .section __DATA,__data > _tst2: ## @tst2 > .ascii "\000\001\002\003" > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to deal with dllexports in '...

...the Mangler::getValueName() method will produce something > like "__unnamed_1_37" for a global value that doesn't have a name. > This is wrong for Objective-C where CFStrings will get these labels, > thus preventing the linker from coalescing them. > > [/tmp]> nm -s __DATA __cfstring -m foo.o > 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 > 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 > ... > > I think that prepending the PrivateGlobalPrefix to these names would > be the way to go. My question is whether getValu...

On May 7, 2010, at 11:42 AM, Nathan Jeffords wrote: >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >> .section __DATA,__data >> _tst2: ## @tst2 >> .ascii "\000\001\002\003" >> >> I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the latter to...

...>> >> Macho has a special zerofill directive (targeted at the BSS section) for >> this. You can see this by running your example like this: >> >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >> .section __DATA,__data >> _tst2: ## @tst2 >> .ascii "\000\001\002\003" >> > > I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream > methods, the latter t...

...er %ebp pushl %esi .cfi_offset %esi, -12 movb 16(%ebp), %al movb 12(%ebp), %cl movb 8(%ebp), %dl movl _scscx, %esi movb %dl, (%esi) movl _scscx, %edx movb %cl, 1(%edx) movl _scscx, %ecx movb %al, 2(%ecx) xorl %eax, %eax popl %esi popl %ebp retl .cfi_endproc .comm _pp,3,0 .section __DATA,__data .globl _scscx .p2align 3 _scscx: .long _pp Again, the _scscx is loaded three times instead of reusing a register, which is suboptimal. NOW, if I replace the original code by this: int pp[3]; int *scscx = pp; int tst( int i, int j, int k ) { scscx[0] = i; scscx[1] = j; scscx[2]...

...C Garbage Collection Version", i32 0 } !2 = metadata !{ i32 1, metadata !"Objective-C Garbage Collection", i32 2 } !3 = metadata !{ i32 3, metadata !"Objective-C Garbage Collection", metadata !{ metadata !"Objective-C Image Info Section", metadata !"__DATA, __objc_imageinfo, regular, no_dead_strip" } } !4 = metadata !{ i32 1, metadata !"Objective-C Image Info Section", metadata !"__DATA, __objc_imageinfo, regular, no_dead_strip" } !llvm.module.flags = !{ !0, !1, !2, !3, !4 } Module B -------- !0 = metadata...

...const std::type_info &test2() { return typeid(A); } const std::type_info &test3() { return typeid(B); } const std::type_info &test4() { return typeid(C); } daysthatwere clang$ clang /tmp/red.cpp -c -o red.o daysthatwere clang$ nm -m red.o | grep __ZTI | c++filt 0000000000000120 (__DATA,__datacoal_nt) weak external typeinfo for A (undefined) external typeinfo for B 0000000000000150 (__DATA,__const) external typeinfo for C (undefined) external typeinfo for char const* 0000000000000100 (__DATA,__datacoal_nt) weak external typeinfo for char const**...

...i demangler is its size. It's at least twice as large as the one > in elftoolchain, even ignoring some possible feature differences. Looks pretty good, I'm guessing this is because all the string operations aren't getting inlined into the parser anymore. Before this patch: __TEXT __DATA __OBJC others dec hex 247293 0 0 1248 248541 3cadd libc++abi.a(cxa_demangle.cpp.o) After this patch: __TEXT __DATA __OBJC others dec hex 137723 4216 0 6016 147955 241f3 libc++abi.a(cxa_demangle.cpp.o) > > Joerg > ______...

...ersion", i32 0 } > !2 = metadata !{ i32 1, metadata !"Objective-C Garbage Collection", i32 2 } > !3 = metadata !{ i32 3, metadata !"Objective-C Garbage Collection", >  metadata !{ >    metadata !"Objective-C Image Info Section", >    metadata !"__DATA, __objc_imageinfo, regular, no_dead_strip" >  } > } > !4 = metadata !{ i32 1, metadata !"Objective-C Image Info Section", >                 metadata !"__DATA, __objc_imageinfo, regular, no_dead_strip" } > !llvm.module.flags = !{ !0, !1, !2, !3, !4 } > >...

...} >> !2 = metadata !{ i32 1, metadata !"Objective-C Garbage Collection", i32 2 } >> !3 = metadata !{ i32 3, metadata !"Objective-C Garbage Collection", >> metadata !{ >> metadata !"Objective-C Image Info Section", >> metadata !"__DATA, __objc_imageinfo, regular, no_dead_strip" >> } >> } >> !4 = metadata !{ i32 1, metadata !"Objective-C Image Info Section", >> metadata !"__DATA, __objc_imageinfo, regular, no_dead_strip" } >> !llvm.module.flags = !{ !0, !1, !2...

...atrix_index3.o bdsmatrix_prod.o bdsmatrix_prod2.o bdsmatrix_prod3.o chinv4.o chinv5.o cholesky4.o cholesky5.o chsolve4.o chsolve5.o coxfit6a.o coxfit6b.o coxfit6c.o gchol.o gchol_bds.o -lcc_dynamic -framework R ld: multiple definitions of symbol _coxfit6 agfit6b.o definition of _coxfit6 in section (__DATA,__common) coxfit6a.o definition of _coxfit6 in section (__DATA,__common) coxfit6b.o definition of _coxfit6 in section (__DATA,__common) coxfit6c.o definition of _coxfit6 in section (__DATA,__common) make: *** [kinship.so] Error 1 ERROR: compilation failed for package 'kinship' ** Removing &...

Thanks! Yes, we are trying to avoid that situation as much as possible. Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)? Currently I don't know any better way than runtime logging and asserting. Also, what shall we do we external source libraries (like Teigha from Open Design Alliance), where

...r/lib/libm.dylib(getopt.o) definition of _getopt ../share/libgetopt.a(getopt.o) definition of _getopt in section (__TEXT,__text) /usr/bin/ld: multiple definitions of symbol _optarg /usr/lib/libm.dylib(getopt.o) definition of _optarg ../share/libgetopt.a(getopt.o) definition of _optarg in section (__DATA,__common) /usr/bin/ld: multiple definitions of symbol _opterr /usr/lib/libm.dylib(getopt.o) definition of _opterr ../share/libgetopt.a(getopt.o) definition of _opterr in section (__DATA,__data) /usr/bin/ld: multiple definitions of symbol _optind /usr/lib/libm.dylib(getopt.o) definition of _optind...