FW: strip incompatible with gcc -Wl,-taso linker option on Alpha ?

[Jim McCarthy]

Apologies in advance for cross-posting this to axp-list, but
I received a reply from Nick Clifton (nickc at redhat) stating
"binutils" is now at version 2.15 ...

Hence I wonder if anyone out there in axp-list land might be
willing to cut/paste my simple "taso_strip_test.c" code from
the posting below, and walk through the steps that follow "$"
on your Alpha (assuming strip -V on your platform [AlphaCore?]
reports something closer to 2.15 than 2.11.90 on my Digital
Personal Workstation 600au running RH7.2 for Alpha ...).

At issue is whether "long" (64-bit) address pointers show up
after strip is invoked on executables compiled (linked) using
"gcc -Wl,-taso"  (or simply "ld -taso", if gcc -c is used).
(BTW, taso stands for "truncated address space option", and is
a linker option that restricts an executable's address space
to the lower 31-bit range ... allowing code that does 32-bit
integer arithmetic on pointers to still work, in spite of the
default pointer address length on 64-bit Alpha being >32-bits).

Naturally I'm especially interested to hear reports of success
(addresses remaining the same after invoking strip as before)
and what version of strip (binutils) you're running on what
Linux kernel.

Thanks in advance,

      -- Jim McCarthy


-----Original Message-----
From: Jim McCarthy
Sent: Thursday, January 06, 2005 9:07 AM
To: gcc at gcc.gnu.org
Cc: Richard Henderson; bug-binutils at gnu.org
Subject: strip incompatible with gcc -Wl,-taso linker option on
         Alpha ?
 
First, belated thanks to Richard Henderson for his reply to my
earlier query (thread: -xtaso_short option on DEC Alpha Linux ?).
 
Taking his advice, we proceeded to add the "-Wl,-taso" switch to
gcc (for the linker) and build the 32-bit software package I'm
trying to port from IA32 Linux to DEC Alpha Linux (RH7.2).  Only
partly successful:  simpler applications worked fine, but others
reported a "Fatal internal error".  These we traced to malloc()
requests for small amount of memory workspace properly returning
addresses <32-bits but all larger memory requests were returning
addresses >32-bits, causing the failures.
 
At long last, we've finally traced the problem to the software's
build script invoking "strip" on the resulting executables.  If
I run the applications *before* strip, they work fine, as *all*
malloc() requests properly return <32-bit addresses.
 
On my RH7.2 installation on DEC Alpha, strip -V reports version
"GNU strip 2.11.90.0.8"
 
I have tried invoking strip with the available options (one at
a time only):  --strip-all, --strip-debug, --strip-unneeded,
--discard-all, or --discard-locals ... and regardless of the
option used, a -Wl,-taso executable that previously returned
<32-bit memory addresses from malloc() was found to return
(undesired) >32-bit addresses *after* the strip step.
 
I'm happy to be "up and running" with my applications on Alpha
now (having commented-out the strip step in the build script),
but nevertheless it would be "nice" to have smaller executable
files, if possible via strip.  This isn't a *high* priority,
but nevertheless I thought I should bring it to your attention.
 
Any chance a strip (binutils) version later than 2.11.90.0.8
may have already addressed incompatibility with gcc -Wl,-taso
(and still be compatible with my RH7.2 Alpha Linux kernel) ?
 
Thanks in advance for any fixes/suggestions,

     -- Jim

/*
** taso_strip_test.c starts with line above
*/

#include <malloc.h>
#include <stdio.h>

int main()
{
    void * P;
    int  bytes;
    int  i;

    for (i=1; i<=10; i++)
    {
       bytes = (i*i) * 1024 * sizeof(float);
       P = malloc(bytes);
       printf ("%d bytes of memory allocated at %p\n",bytes,P);
       free(P);
    }
    return 0;
}
/*
** taso_strip_test.c ends with line below
*/

$ gcc -Wl,-taso -O -o test taso_strip_test.c
$ test
  ...all memory addresses returned are <32-bits
$ strip test
$ test
  ...some memory addresses returned are >32-bits

On my machine (DEC Personal Workstation 600au, 1.5Gb of RAM),
malloc() requests of 102400 bytes or fewer return 0x12010ae0
while requests for 147456 bytes or more return 0x401da010 (OK)
before strip, but 0x200001da010 (not OK) after strip.  Others
may(?) need to adjust the loop limit "10" or formula for bytes
to get the test program to span the OK/not-OK boundary after
strip on your machine.
_____________________________________________________________

On Mon, November 22, 2004 10:52AM, Richard Henderson wrote:
> 
> On Mon, Nov 22, 2004 at 06:55:15AM -0800, Jim McCarthy wrote:
>> Given that the GNU linker supports the -taso switch, I am 
>> curious to know if gcc support for -xtaso and especially
>> -xtaso_short on DEC Alpha Linux is far behind ?
> 
> There are no plans to ever support this option.
> 
> You can *usually* get away with just ignoring the cast warnings
> and supplying the -taso switch to the linker.  Pointers *will*
> still be 64 bits, but due to the link switch only 31 bits will
> ever be set, which means that the cast-to-int and back will work.
> 
> This only fails to work when you've got pointers in structures
> that wind up in external data formats, or if you assume structure
> sizes instead of using sizeof or offsetof.
> 
> r~