Re: -taso flag?
BTW, I'm cc'ing debian-alpha on this in case there's any similar questions
in people's heads :-)
On 19 Jan 2000, Ron Farrer wrote:
> Compile it normally, i.e. "cc var_size.c -o var_size" to make sure it
> works then try using the 32-bit flag.
>
> Shouldn't both the 32-bit and 64-bit versions be indentified correctly
> by file?
Ok, my test programme is nearly identical to yours, so this is easy to
comment on (I've been messing with this since you wrote the first email to
me).
Here's the scoop: the -taso flag doesn't alter anything but the base
memory address space. It won't "scale" down the sizes of things, but
makes it so that pointer addresses will truncate and still fit into an
int-sized variable. So, it won't act like using a SMALL memory model (to
liken it to Windows development models in the past), where it would resize
ints and longs to act just like i386's, but it will scale down where the
memory locations are so that they fit in the lower 32-bit address space,
thus making them safe for people that do pointer arithematic or assign
memory addresses to 32-bit ints.
> $ file var_size_32-bit
> var_size_32-bit: ELF 64-bit LSB executable, Alpha (unofficial), version
> 1, dynamically linked (uses shared libs), not stripped
>
> $ file var_size_64-bit
> var_size_64-bit: ELF 64-bit LSB executable, Alpha (unofficial), version
> 1, dynamically linked (uses shared libs), not stripped
The file info won't change. We never changed to using an ELF32 file
format (which we wouldn't want to do), just modified where the linker
places things in memory. FYI, I'm not sure the Linux kernel on Alpha
supports elf32alpha anymore (not since the BLADE days, if I remember
correctly), but I could be wrong.
> I thought maybe I was just missing something?
Kinda...I think the problem was that you misunderstood what the thing
actually did. Try this:
objdump -x var_size_64-bit > 64.dump
objdump -x var_size_32-bit > 32.dump
and diff the two using the -uN flags to diff (unified, context aware).
Now, in that diff, take a look at the differences in the memory locations.
They should be shifted down to an identically-numbered (or close to it)
address that will fit in 32-bit ints.
Here's a sample from my test programme (it's only a snippet):
- 11 .fini 0000004c 0000000120000680 0000000120000680 00000680
2**5
+ 11 .fini 0000004c 0000000012000680 0000000012000680 00000680
2**5
CONTENTS, ALLOC, LOAD, READONLY, CODE
- 12 .rodata 00000047 00000001200006cc 00000001200006cc 000006cc
2**2
+ 12 .rodata 00000047 00000000120006cc 00000000120006cc 000006cc
2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
- 13 .data 00000008 0000000120100718 0000000120100718 00000718
2**3
+ 13 .data 00000008 0000000012100718 0000000012100718 00000718
2**3
I snagged the .data section especially so that you can see the differences
(that's the spot that really matters). Check the second and third columns
of the last two lines...
Let me know if you have any questions. I'm glad it worked and proud to
say that we're the first linux dist that's going to include -taso in the
binutils package in a release distribution :-)
C
Reply to: