Bug 12885 - gcc targetting hppa uses memcpy() with -fno-builtin
Summary: gcc targetting hppa uses memcpy() with -fno-builtin
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.2
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-03 14:01 UTC by phil@secdev.org
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i386-pc-linux-gnu
Target: hppa-unknown-linux-gnu
Build: i386-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description phil@secdev.org 2003-11-03 14:01:53 UTC
When using initialization for variables in the stack, data
must be copied from the .rodata section to the stack.
When the target is hppa, memcpy() is used, even if -fno-builtins is used.

Environment:
System: Linux rigel 2.4.21 #1 Tue Aug 19 13:11:08 CEST 2003 i686 GNU/Linux
Architecture: i686
host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: hppa-unknown-linux-gnu
configured with: ../src/configure -v --enable-languages=c --prefix=/usr
--infodir=/usr/share/info --mandir=/usr/share/man
--with-gxx-include-dir=/usr/hppa-linux/include/g++ --enable-shared
--with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long
--enable-nls --without-included-gettext --disable-checking
--build=i386-linux --host=i386-linux --target=hppa-linux

How-To-Repeat:
$ cat hello.c
int main(void)
{
        char buf[] = "Hello world!\n";
        write(1, buf, sizeof(buf));
}
$ hppa-linux-gcc -S -o - -fno-builtins hello.c
        .LEVEL 1.1
        .section        .rodata
        .align 4
.LC0:
.stringz"Hello world!\n"
        .text
        .align 4
.globl main
                .type            main,@function
main:
        .PROC
        .CALLINFO FRAME=128,CALLS,SAVE_RP,SAVE_SP,ENTRY_GR=3
        .ENTRY
        stw %r2,-20(%r30)
        copy %r3,%r1
        copy %r30,%r3
        stwm %r1,128(%r30)
        ldil LR'.LC0,%r19
        ldo RR'.LC0(%r19),%r19
        ldo 8(%r3),%r20
        ldi 14,%r21
        copy %r20,%r26
        copy %r19,%r25
        copy %r21,%r24
        bl memcpy,%r2  <<<< Here
        nop
        ldi 1,%r26
        ldo 8(%r3),%r25
        ldi 14,%r24
        bl write,%r2
        nop
        ldi 5,%r26
        bl exit,%r2
        nop
        nop
        .EXIT
        .PROCEND
.Lfe1:
        .size   main,.Lfe1-main
        .ident  "GCC: (GNU) 3.2.3 20030221 (Debian prerelease)"
Comment 1 phil@secdev.org 2003-11-03 14:01:53 UTC
Fix:
??
Comment 2 Falk Hueffner 2003-11-03 15:42:38 UTC
-fno-builtin is not supposed to suppress generation of libcalls; it just turns
off special recognition of libc functions. You probably want -ffreestanding.
Comment 3 Andrew Pinski 2003-11-03 15:49:11 UTC
But -ffreestanding does not work, at least right on 3.4.
Comment 4 phil@secdev.org 2003-11-03 17:45:53 UTC
Subject: Re:  gcc targetting hppa uses memcpy() with -fno-builtin

yOn 3 Nov 2003, falk at debian dot org wrote:

> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12885
>
>
> falk at debian dot org changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |RESOLVED
>          Resolution|                            |INVALID
>
>
> ------- Additional Comments From falk at debian dot org  2003-11-03 15:42 -------
> -fno-builtin is not supposed to suppress generation of libcalls; it just turns
> off special recognition of libc functions. You probably want -ffreestanding.
>

You are right. In fact, I use -ffreestanding, which does not work. I
misinterpreted -fno-builtin thinking that it was the misbehaving option.
Please replace any reference to -fno-builtin by -ffreestanding in this
bug report (ie: "gcc targetting hppa uses memcpy() with -ffreestanding").



Comment 5 Falk Hueffner 2003-11-03 19:17:22 UTC
It turns out that current policy is to emit some function calls even with
-ffreestanding. See bug 4417.