similar to: [LLVMdev] AsmPrinter : SwitchToSection

On Apr 27, 2007, at 3:50 PM, David Greene wrote: > The saga continues. > > I've been tracking the interface changes and merging them with > the refactoring work I'm doing. I got as far as building stage3 > of llvm-gcc but the object files from stage2 and stage3 differ: > > > warning: ./cc1-checksum.o differs > warning: ./cc1plus-checksum.o differs > >

From: Sylvain Gault <sylvain.gault at gmail.com> Some linker scripts were splitted into i386 and x86_64 versions in commit d8eede3f2a360163235fad222a0190cd7c5bef38 but older scripts were left there. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- core/syslinux.ld | 414 ------------------------------------------------ core/x86_64/syslinux.ld | 389

Commit-ID: 048bfb0df170d4a43142adcee8a2dffdfc2c1e9f Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=048bfb0df170d4a43142adcee8a2dffdfc2c1e9f Author: James Cowgill <james.cowgill at mips.com> AuthorDate: Fri, 2 Mar 2018 08:33:01 -0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Wed, 2 Jan 2019 03:08:04 +0000 [klibc] mips: use -Ttext-segment

+llvm-dev properly this time. On Fri, 10 Mar 2017 at 09:42 James Molloy <james at jamesmolloy.co.uk> wrote: > Hi Reid, all, > > +llvm-dev as this RFC involves changes in Clang and LLVM. > > This RFC has stagnated and I think that's partially because the proposal > isn't particularly elegant and is light on details. We've been having a > rethink and have a

We need to build with -mno-pic to disable all uses of GP, as well as use a custom linker script to avoid collisions between klibc.so's and the executable's segments. Signed-off-by: James Clarke <jrtc27 at jrtc27.com> --- usr/klibc/arch/ia64/MCONFIG | 3 + usr/klibc/arch/ia64/crt0.S | 4 - usr/klibc/arch/ia64/klibc.ld | 267 ++++++++++++++++++++++++++++++++++++++++++

Commit-ID: 8418552770110e9864ab24d60d8481fac58d3a65 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=8418552770110e9864ab24d60d8481fac58d3a65 Author: James Clarke <jrtc27 at jrtc27.com> AuthorDate: Mon, 21 Jan 2019 21:26:57 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Mon, 21 Jan 2019 22:51:27 +0000 [klibc] ia64: Fix shared build We

On 7 May 2010 18:14, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > > On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> >> This seems counter intuitive to me, I can understand that C assigned that >>> behavior

On Fri, May 7, 2010 at 10:14 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > > On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> >> This seems counter intuitive to me, I can understand that C assigned that

On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: > > This seems counter intuitive to me, I can understand that C assigned that >> behavior somewhat arbitrarily to uninitialized global variables, but in LLVM >> there is explicitly a common linkage attribute to get that behavior. Nothing >>

How are you modeling weak aliases in Atoms? mach-o does not support weak aliases. My mental model of a weak alias is: If foo is a weak alias for bar, then if nothing else defines bar, use foo in place of bar. -Nick On Jan 8, 2013, at 4:50 PM, Michael Spencer wrote: > So I just got lua to link and run and work on x86-64 Linux with musl > and lld. It did require one change to hack

On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: >> This seems counter intuitive to me, I can understand that C assigned that behavior somewhat arbitrarily to uninitialized global variables, but in LLVM there is explicitly a common linkage attribute to get that behavior. Nothing in the llvm language reference indicates the behavior of a global with the 'internal' linkage attribute

On May 7, 2010, at 10:02 AM, Aaron Gray wrote: > On 7 May 2010 17:53, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 9:51 AM, Nathan Jeffords wrote: > >>> This seems counter intuitive to me, I can understand that C assigned that behavior somewhat arbitrarily to uninitialized global variables, but in LLVM there is explicitly a common linkage

Hi XCore and PIC16 maintainers, I'd appreciate it if you guys could move your AsmPrinter implementation to be in a subdirectory like the rest of the other targets (e.g. make it live in lib/Target/PIC16/AsmPrinter). Anton is planning to move MSP430 to use the same approach. Having all the targets use the same design simplifies the build system and keeps the target architecture more

dos/syslinux.elf fails to build on current Ubuntu Natty (binutils 2.21) as follows: ld -m elf_i386 -T dosexe.ld -o syslinux.elf header.o crt0.o ldlinux.o syslinux.o fat.o syslxmod.o syslxopt.o setadv.o getopt_long.o bootsect_bin.o mbr_bin.o cache.o fatchain.o open.o searchdir.o libcom.a /usr/bin/ld.bfd.real: syslinux_ldlinux_size must equal the size of .payload /usr/bin/ld.bfd.real:

> Hi Sachin, > > The declaration of functions called via the "call" instruction is a > GlobalValue in your Module. You can go through all of the > GlobalValues, look for those that are Function declarations (use the > "Function::isDeclaration()" method), and then placing them in the > appropriate place in your assembly file. > > Would that work? Hi

Hi Sachin, The declaration of functions called via the "call" instruction is a GlobalValue in your Module. You can go through all of the GlobalValues, look for those that are Function declarations (use the "Function::isDeclaration()" method), and then placing them in the appropriate place in your assembly file. Would that work? -bw On Jan 28, 2009, at 12:23 AM,

Hi Reid, Unfortunately yes, it is. > If we do go with approach 3, I'd recommend adding a single metadata attachment that controls all sections a global could possibly live in (text, data, rdata, bss). I agree with this, although I think using metadata here wouldn't be right - don't we need to use attributes when dropping metadata would cause miscompiles? I was considering adding

Hi, Probably I did not mention my question correctly. I need to emit declarations of the libcalls (that are made in the current module) at the beginning of the assembly file. The class "Module" does not maintain any list of the libcalls made during the program. Although, it maintains lists of all the global variables and functions in the current module. Traversing each

On Fri, May 7, 2010 at 9:01 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 12:39 AM, Nathan Jeffords wrote: > > On Fri, May 7, 2010 at 12:03 AM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 6, 2010, at 10:01 PM, Nathan Jeffords wrote: >> >> > I compile these two lines in llc >> > >> >

Thanks Reid/Jonathon for your replies. Reid, An important case against module level flags is that it wont allow changing or resetting section names e.g. int a; #pragma clang section bss = "xyz" int b; In case above, users would like to see only 'b' placed in 'xyz' and not 'a' as well. Link pointed to by Jonathon seems to require same behavior.