|
Message
From: Matjaz Breskvar<phoenix@o...>
Date: Mon Feb 21 01:42:50 CET 2005
Subject: [openrisc] x86_64 linux [more&more]
* Balint Cristian (rezso@r...) wrote:
> Hello,
>
> Today several hours i drag cc1 into ddd but no much luck,
> only the mention [i add it to previous mail where i point out the emmited
> pattern in or32.c where it fail/problematic] that one super constructed
> pointer-to-pointer to a table has 0x1000000000000000 value instead of 0x0 so
> emmited value will be 1152921....6976 [in decimal]
> as i dump/watch it in the contain of memory.
>
> I think this value in *operand more exacly in someting *x wich hold
> u.hwint[0] is wrongly initialized or only halfly [must be 64 bit long inited
> on x86_64] somewhere at code generation,
> and at final assamblation/asm-file dump to hardisk in final.c it take the huge
> value instead of 0x0 [as observed/compared to i386 host machine]
>
> For today i blow my brain ... :)
>
> If find the time please comment on my issue, any small idea even if it is
> vague will help me, i try to figure out.
this is an interesting diff between i386 and x86-64 generated assembly...
the 268435456 just happens to be 0x10000000, so it's the upper part of
1152921504606846976. My really wild guess would be that some code assumes
target register size = host register size...
- .section .rodata
- .align 4
-.LC1:
- .long 268435456
- .long 0
-.section .text
-.L300:
- l.movhi r3,hi(.LC1) # move immediate (high)
- l.ori r3,r3,lo(.LC1) # move immediate (low)
+.L318:
+ l.or r13, r0, r0
+ l.movhi r14, hi(1152921504606846976)
+ l.ori r14, r14, lo(1152921504606846976)
best regards,
p.
|
 |
Browse
