This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]