search for: gotoff

>> Any thoughs? > > I'm now struggling to see how GCC justifies it. What if a different > translation-unit declared those variables in a different order? I also > can't get the same behaviour here, do you have a more complete > command-line? Ah, I see; the translation-unit that does the optimisation needs to have them as a definition (i.e. "= {0}") rather

...extern int *dptr; // .extern dptr void DataLoadAndStore() { // Large Memory Model code sequences from AMD64 abi // Figure 3.22: Position-Independent Global Data Load and Store // // Assume that %r15 has been loaded with GOT address by // function prologue. // movabs $Lsrc at GOTOFF,%rax ; R_X86_64_GOTOFF64 // movabs $Ldst at GOTOFF,%rdx ; R_X86_64_GOTOFF64 // movl (%rax,%r15),%ecx // movl %ecx,(%rdx,%r15) dst = src; // movabs $dptr at GOT,%rax ; R_X86_64_GOT64 // movabs $Ldst at GOTOFF,%rdx ; R_X86_64_GOTOFF64 // movq (%rax,%r15),%rax // leaq (...

...i32]* @g0 to i8*)) tail call void @bar(i8* bitcast ([100 x i32]* @g1 to i8*)) ret void } declare void @bar(i8*) The command "llc -mtriple=i686-pc-linux -relocation-model=pic" produces calll .L0$pb .L0$pb: popl %ebx .Ltmp3: addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp3-.L0$pb), %ebx leal g0 at GOTOFF(%ebx), %eax movl %eax, (%esp) calll bar at PLT leal g1 at GOTOFF(%ebx), %eax movl %eax, (%esp) calll bar at PLT Which is ok , since the add of ebx is folded and the constant is an immediate in x86. On ARM, that is not the case. We produce ldr r0, .LCPI0_0 add r4, pc, r0 /...

On 10 December 2013 15:35, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > Without it, -save-temps is broken. As such it falls into a pretty > basic use case. Hi Joerg, I couldn't find anything in bugzilla that matched your description, but it seems like a pretty bad problem, can you point us to the discussion so we can decide whether it should be fixed now, or after the

...retty bad problem, can you point us to the > discussion so we can decide whether it should be fixed now, or after > the move. I haven't created a bug report yet. From memory, the following things are missing and higher-priority: Pseudo-ops: .abicalls .fpu .arch .cpu Modifiers: foo(GOTOFF) foo(GOT) foo(PLT) ldr is a separate issue with a pending patch. Joerg

...ty: This is looking hopeful. > Pseudo-ops: > .abicalls This is MIPS-only. > .fpu > .arch > .cpu I think there was some opinion that directives like these weren't essential (well, I certainly hold the opinion!) > Modifiers: > foo(GOTOFF) > foo(GOT) > foo(PLT) I think David fixed these in r196424. > ldr is a separate issue with a pending patch. Yep. It'll probably go in in the next few days. Just as soon as we chain Jim to a computer long enough to give it his blessing. Cheers. Tim.

...Ltmp4: .cfi_def_cfa_offset 8 .Ltmp5: .cfi_offset %ebp, -8 movl %esp, %ebp .Ltmp6: .cfi_def_cfa_register %ebp pushl %ebx subl $20, %esp .Ltmp7: .cfi_offset %ebx, -12 calll .L0$pb .L0$pb: popl %eax .Ltmp8: addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp8-.L0$pb), %eax movl 8(%ebp), %ecx leal .L.str at GOTOFF(%eax), %edx movl %ecx, -8(%ebp) .loc 1 13 2 prologue_end # a.c:13:2 .Ltmp9: movl -8(%ebp), %ecx movl %edx, (%esp) movl %ecx, 4(%esp) movl %eax, %ebx calll printf at PLT .loc 1 14 1 # a.c:14:1 movl %eax, -12(%ebp) # 4-byte Spill addl $20, %esp popl %ebx popl...

...irectives like these weren't > essential (well, I certainly hold the opinion!) At least either .march or .cpu is required for dealing with the infamous "you have the wrong CPU to use instruction X" issue. I'm not sure about .fpu yet. > > Modifiers: > > foo(GOTOFF) > > foo(GOT) > > foo(PLT) > > I think David fixed these in r196424. Will test this ASAP. > > ldr is a separate issue with a pending patch. > > Yep. It'll probably go in in the next few days. Just as soon as we > chain Jim to a computer long...

...tends. For > example, a frontend may need to represent some other kind of > custom/specific > instruction sequence in IR, or to create arbitrary kinds of references > between > objects where that may be beneficial (for example, -fsanitize=function may > use this facility to create GOTOFF relocations in function prologues to > avoid creating dynamic relocations in the .text section to fix PR17633). > > Thanks, > -- > Peter > > [1] http://www.pcc.me.uk/~peter/acad/usenix14.pdf > > -------------- next part -------------- An HTML attachment was scrubbed... UR...

...sed for other purposes by frontends. For example, a frontend may need to represent some other kind of custom/specific instruction sequence in IR, or to create arbitrary kinds of references between objects where that may be beneficial (for example, -fsanitize=function may use this facility to create GOTOFF relocations in function prologues to avoid creating dynamic relocations in the .text section to fix PR17633). Thanks, -- Peter [1] http://www.pcc.me.uk/~peter/acad/usenix14.pdf

Up to now I have got the base R and about half of the packages working on SuSe Linux 5.3 using gcc, g77 and xdevel. The other half, for example: pspline, logspline, KernSmooth, akima, tripack, ppr, principal.curve, cluster, funfit, repeated, event, etc., just won't install. Some of them give warnings at expressions in subroutines (repeated, event, pspline,etc.. I will ask about this in

Up to now I have got the base R and about half of the packages working on SuSe Linux 5.3 using gcc, g77 and xdevel. The other half, for example: pspline, logspline, KernSmooth, akima, tripack, ppr, principal.curve, cluster, funfit, repeated, event, etc., just won't install. Some of them give warnings at expressions in subroutines (repeated, event, pspline,etc.. I will ask about this in

...y for good diagnostics ================================ In a few linker scripts in the kernel, there is a comment like this: /DISCARD/ : { /* * Discard any r/w data - this produces a link error if we have any, * which is required for PIC decompression. Local data generates * GOTOFF relocations, which prevents it being relocated independently * of the text/got segments. */ *(.data) } It would be nice if there were some way to directly provide them with the check that they want here and give a nice explanatory diagnostic if it fails. Another place for good dia...