Re: -taso flag?

["Christopher C. Chimelis" <chris@debian.org>]

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