public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c/4391: memcpy(buf, base, len); defunction compiling bind with -O2
@ 2002-04-24 15:22 rth
0 siblings, 0 replies; 3+ messages in thread
From: rth @ 2002-04-24 15:22 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, georg.wild, nobody
Synopsis: memcpy(buf, base, len); defunction compiling bind with -O2
State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Wed Apr 24 15:22:18 2002
State-Changed-Why:
Presumed fixed by Graham's patch. File another PR if not,
and do include the preprocessed file.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4391
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c/4391: memcpy(buf, base, len); defunction compiling bind with -O2
@ 2001-09-25 4:16 Graham Stott
0 siblings, 0 replies; 3+ messages in thread
From: Graham Stott @ 2001-09-25 4:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/4391; it has been noted by GNATS.
From: Graham Stott <grahams@redhat.com>
To: georg.wild@gmx.de
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/4391: memcpy(buf, base, len); defunction compiling bind with -O2
Date: Tue, 25 Sep 2001 18:10:17 +0700
georg.wild@gmx.de wrote:
>
> >Number: 4391
> >Category: c
> >Synopsis: memcpy(buf, base, len); defunction compiling bind with -O2
> >Confidential: no
> >Severity: serious
> >Priority: medium
> >Responsible: unassigned
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Tue Sep 25 03:36:01 PDT 2001
> >Closed-Date:
> >Last-Modified:
> >Originator: georg.wild@gmx.de
> >Release: latest cvs snapshot
> >Organization:
> >Environment:
> i686-pc-linux-gnu linux 2.2.19 glibc 2.2.4 and mostly newest libraries
> >Description:
> Sorry, but it was not possible for me producing a compilable example because this bug is somehow connected with libraries and .....! Therefore I'll describe what happens!
> It occurs compiling ftp://ftp.isc.org/isc/bind9/9.2.0rc4/bind-9.2.0rc4.tar.gz and specially libisc.
> The position where it is first seen in the main program is in:
> isc_result_t
> isc_file_progname(const char *filename, char *buf, size_t buflen) {
> const char *base;
> size_t len;
>
> REQUIRE(filename != NULL);
> REQUIRE(buf != NULL);
>
> base = isc_file_basename(filename);
> len = strlen(base) + 1;
>
> if (len > buflen)
> return (ISC_R_NOSPACE);
> memcpy(buf, base, len);
>
> return (ISC_R_SUCCESS);
> }
> When reaching the memcpy line, I see in ddd the program returning to the main program without setting ISC_R_SUCCESS. In the asm tab there is a jmp-Funktion. Pressing next in machine code returns directly to the main program!
I recognize this bug :-) the compiler is incorrectly translating the memcpy call as a sibcall and hence the return ISC_R_SUCCESS
is never executed.
Try the following patch which I'll commit to CVS shortly
ChangeLog
*sibcall.c (skip_copy_to_return_value): Tighten return value
copy check.
-------------------------------------------------------------------
Index: sibcall.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/sibcall.c,v
retrieving revision 1.24
diff -c -p -r1.24 sibcall.c
*** sibcall.c 2001/08/22 14:35:42 1.24
--- sibcall.c 2001/09/09 15:52:37
*************** skip_copy_to_return_value (orig_insn)
*** 159,166 ****
if (return_value_pseudo)
{
! if (SET_DEST (set) == return_value_pseudo)
! return insn;
return orig_insn;
}
--- 159,167 ----
if (return_value_pseudo)
{
! if (SET_DEST (set) == return_value_pseudo
! && SET_SRC (set) == softret)
! return insn;
return orig_insn;
}
---------------------------------------------------------------------
Graham
^ permalink raw reply [flat|nested] 3+ messages in thread
* c/4391: memcpy(buf, base, len); defunction compiling bind with -O2
@ 2001-09-25 3:36 georg.wild
0 siblings, 0 replies; 3+ messages in thread
From: georg.wild @ 2001-09-25 3:36 UTC (permalink / raw)
To: gcc-gnats
>Number: 4391
>Category: c
>Synopsis: memcpy(buf, base, len); defunction compiling bind with -O2
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Sep 25 03:36:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: georg.wild@gmx.de
>Release: latest cvs snapshot
>Organization:
>Environment:
i686-pc-linux-gnu linux 2.2.19 glibc 2.2.4 and mostly newest libraries
>Description:
Sorry, but it was not possible for me producing a compilable example because this bug is somehow connected with libraries and .....! Therefore I'll describe what happens!
It occurs compiling ftp://ftp.isc.org/isc/bind9/9.2.0rc4/bind-9.2.0rc4.tar.gz and specially libisc.
The position where it is first seen in the main program is in:
isc_result_t
isc_file_progname(const char *filename, char *buf, size_t buflen) {
const char *base;
size_t len;
REQUIRE(filename != NULL);
REQUIRE(buf != NULL);
base = isc_file_basename(filename);
len = strlen(base) + 1;
if (len > buflen)
return (ISC_R_NOSPACE);
memcpy(buf, base, len);
return (ISC_R_SUCCESS);
}
When reaching the memcpy line, I see in ddd the program returning to the main program without setting ISC_R_SUCCESS. In the asm tab there is a jmp-Funktion. Pressing next in machine code returns directly to the main program!
But I think the real problem is in file.c, because it works when file.c is compiled -O0. -O2 doesn't work.
Because I don't see any other related function, I think the miscompiled funktion is
const char *
isc_file_basename(const char *filename) {
char *s;
REQUIRE(filename != NULL);
s = strrchr(filename, '/');
if (s == NULL)
return (filename);
return (s + 1);
}
Debugging this piece of code results:
Starting with filename="/root/bind-9.2.0rc4/bin/named/named" s=strrchr(..) results s="/named". Executing this if statement changes the value of s; it got "/root/bind-..../named". After executing the return function the value of s is "named"; executing the whole procedure returns the right value: "named". But I think there seems to be a somehow wrong memory allocation.
>How-To-Repeat:
Compiliung this bind release in the usual manor.
>Fix:
Compile file.c using -O0.
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-04-24 22:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-24 15:22 c/4391: memcpy(buf, base, len); defunction compiling bind with -O2 rth
-- strict thread matches above, loose matches on Subject: below --
2001-09-25 4:16 Graham Stott
2001-09-25 3:36 georg.wild
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).