search for: 74c

...scope_top)($gp) lw $2, %got(body_ok)($gp) lw $3, %lo(scope_top)($3) addiu $2, $2, %lo(body_ok) This is the assembled program generated by gas: $ mips-linux-gnu-objdump -dr z29.gas.o 748: 8f830000 lw v1,0(gp) 748: R_MIPS_GOT16 .bss 74c: 8f820000 lw v0,0(gp) 74c: R_MIPS_GOT16 .bss 750: 8c630000 lw v1,0(v1) 750: R_MIPS_LO16 .bss 754: 244245d4 addiu v0,v0,17876 754: R_MIPS_LO16 .bss...

...)($gp) >  lw  $3, %lo(scope_top)($3) >  addiu $2, $2, %lo(body_ok) > > This is the assembled program generated by gas: > $  mips-linux-gnu-objdump -dr z29.gas.o > >     748:       8f830000        lw      v1,0(gp) >                        748: R_MIPS_GOT16       .bss >     74c:       8f820000        lw      v0,0(gp) >                        74c: R_MIPS_GOT16       .bss >     750:       8c630000        lw      v1,0(v1) >                        750: R_MIPS_LO16        .bss >     754:       244245d4        addiu   v0,v0,17876 >                        754: R_M...

...)($3) >> addiu $2, $2, %lo(body_ok) >> >> This is the assembled program generated by gas: >> $ mips-linux-gnu-objdump -dr z29.gas.o >> >> 748: 8f830000 lw v1,0(gp) >> 748: R_MIPS_GOT16 .bss >> 74c: 8f820000 lw v0,0(gp) >> 74c: R_MIPS_GOT16 .bss >> 750: 8c630000 lw v1,0(v1) >> 750: R_MIPS_LO16 .bss >> 754: 244245d4 addiu v0,v0,17876 >>...

Hi Akira, If I follow correctly, the relocation entries can thus be in a different order than the instructions that they're for? That seems a bit odd, but I suppose there's nothing inherently wrong with that. It's just not something, AFAIK, that llvm has had to deal with before. This should definitely be a target-specific thing, not a general ELFObjectWriter thing, as other targets

What would be the best way to sort relocation entries before they are written out in ELFObjectWriter::WriteRelocationsFragment? According to the Mips ABI documents I have, there are certain restrictions on the order relocations appear in the table (e.g. R_MIPS_HI16 and R_MIPS_GOT16 must be followed immediately by a R_MIPS_LO16). When I enable post RA scheduling, some of the restrictions are

...$2, %lo(body_ok) >>> >>> This is the assembled program generated by gas: >>> $  mips-linux-gnu-objdump -dr z29.gas.o >>> >>>     748:       8f830000        lw      v1,0(gp) >>>                        748: R_MIPS_GOT16       .bss >>>     74c:       8f820000        lw      v0,0(gp) >>>                        74c: R_MIPS_GOT16       .bss >>>     750:       8c630000        lw      v1,0(v1) >>>                        750: R_MIPS_LO16        .bss >>>     754:       244245d4        addiu   v0,v0,17876 >...

...gt; >>>> This is the assembled program generated by gas: >>>> $ mips-linux-gnu-objdump -dr z29.gas.o >>>> >>>> 748: 8f830000 lw v1,0(gp) >>>> 748: R_MIPS_GOT16 .bss >>>> 74c: 8f820000 lw v0,0(gp) >>>> 74c: R_MIPS_GOT16 .bss >>>> 750: 8c630000 lw v1,0(v1) >>>> 750: R_MIPS_LO16 .bss >>>> 754: 244245d4 addiu...

...tub! fixme:imm:ImmGetOpenStatus (0x13c9f0): semi-stub fixme:imm:ImmReleaseContext (0x10026, 0x13c9f0): stub fixme:imm:ImmGetOpenStatus (0x13c9f0): semi-stub fixme:imm:ImmGetOpenStatus (0x13c9f0): semi-stub fixme:advapi:LookupAccountNameW L"" L"egondolf" (nil) 0x32e744 (nil) 0x32e74c 0x 32e748 - stub fixme:advapi:LookupAccountNameW L"" L"egondolf" 0x1a4870 0x32e744 0x1a48c0 0x32e 74c 0x32e748 - stub fixme:advapi:LookupAccountNameW L"" L"egondolf" (nil) 0x32e744 (nil) 0x32e74c 0x 32e748 - stub fixme:advapi:LookupAccountNameW L""...

...3 6f 6e arpl %bp,0x6e(%edi) > 6d0: 66 data16 > 6d1: 6c insb (%dx),%es:(%edi) > 6d2: 69 63 74 5f 70 00 74 imul $0x7400705f,0x74(%ebx),%esp > > -000006d8 <__FUNCTION__.22492>: > - 6d8: 74 72 je 74c <__FUNCTION__.22568+0x64> > - 6da: 75 65 jne 741 <__FUNCTION__.22568+0x59> > +000006d8 <__FUNCTION__.22405>: > + 6d8: 74 72 je 74c <__FUNCTION__.22481+0x64> > + 6da: 75 65 jne 741 <__FUNCTION__.22481+0x...

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 (Are the above two ok?) The list below is clearly bad. I think it's every object file in the

Hi Folks, I''ve got a 3.9 Tb zpool, and it is casing kernel panics on my Solaris 10 280r (SPARC) server. The message I get on panic is this: panic[cpu1]/thread=2a100a95cc0: zfs: freeing free segment (offset=423713792 size=1024) This seems to come about when the zpool is being used or being scrubbed - about twice a day at the moment. After the reboot, the scrub seems to have