search for: __used__

Hello, I'm wondering why only some global static variables are marked with __used__ attributes in llvm-gcc/gcc/crtstuff.c. GCC compiles crtstuff.c with -fno-toplevel-reorder option, which ensures that unused static globals are not removed during optimization. However, since LLVM does not support that option, I presume __used__ attribute is used instead. For example, __CTOR_LIST_...

Hello, > __used__ attributes in llvm-gcc/gcc/crtstuff.c. > GCC compiles crtstuff.c with -fno-toplevel-reorder option, which ensures > that > unused static globals are not removed during optimization. However, since > LLVM does not support that option, The problem is not that LLVM does not support this op...

I'd like to discuss the following change: https://reviews.llvm.org/D37526 For the context, there is a comment in compiler-rt/lib/fuzzer/FuzzerExtFunctionsWeak.cpp: // Implementation for Linux. This relies on the linker's support for weak // symbols. We don't use this approach on Apple platforms because it requires // clients of LibFuzzer to pass ``-U _<symbol_name>`` to the

...> I can't think of any way of doing it without essentially trying to > trick the compiler... although there are many ways to trick LLVM. > > Anyone else have ideas? Oh, something I forgot earlier: the generic "don't touch this global" directive is "__attribute__((__used__))". -Eli

...han_dummy_anno"); >__asm__ (".globl " "__stop_set_orphan_dummy_anno"); >static void const > *__set_orphan_dummy_anno_sym_dummy_export_dbg_log_init_linker_set > __attribute__ ((__section__ ("set_" "orphan_dummy_anno"))) > __attribute__ ((__used__)) = &dummy_export_dbg_log_init_linker_set; >============ linker_script ============= : >SECTIONS { > data : { *(data) } ># when commented, the __start and __stop symbols will be protected. How can I keep it from setting it as protected? ># set_orphan_dummy_anno : { PROVIDE(__...

Changes in xen/arch/x86/domain.c in 2.0.2 break comiple for me with: ld --oformat elf32-i386 -T x86_32/xen.lds -N \ boot/x86_32.o /home/root/xen-2.0/xen/common/common.o /home/root/xen-2.0/xen/drivers/char/driver.o /home/root/xen-2.0/xen/drivers/acpi/driver.o /home/root/xen-2.0/xen/drivers/pci/driver.o /home/root/xen-2.0/xen/arch/x86/arch.o -o /home/root/xen-2.0/xen/xen-syms

You are right it creates them but sets the protected flag (STV_PROTECTED) which seems to be the cause of my problem. How can I tell it to set the flag as STV_DEFAULT? Thanks A On 5/28/20, 11:30 PM, "Fangrui Song" <maskray at google.com> wrote: NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know

On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > On Tuesday 13 July 2010 19:48:25 you wrote: >> On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel >> > I thought that the layout of structs was supposed to be preserved (wrong >> > assumption?). Otherwise, any ideas why this happens? >> >> It should be preserved in

On Tuesday 13 July 2010 19:48:25 you wrote: > On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel > > I thought that the layout of structs was supposed to be preserved (wrong > > assumption?). Otherwise, any ideas why this happens? > > It should be preserved in general; Is this a "should" or a "must"? Are there any cases in which structure layout must be

everyone-- I'm trying to build LLVM-GCC as a cross-compiler for a new target. I've successfully patched binutils, the FSF GCC, LLVM and Clang to build for this new target-- they work fine, but the LLVM-gcc build is failing for me. All my llvm.org sources are tracking the Subversion trunk, but my problem is probably not related to any ongoing churn there. I'm doing something