failure notice

failure notice

[Siu.Bun.Chu]

---------------------- Forwarded by Siu Bun Chu/HK/ABNAMRO/NL on 27/11/99 11:59
AM ---------------------------


MAILER-DAEMON@sourceware.cygnus.com on 27/11/99 11:45:46 AM

To:   Siu Bun Chu/HK/ABNAMRO/NL@ABNAMRO
cc:
Subject:  failure notice




Hi. This is the qmail-send program at sourceware.cygnus.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<gcc@gcc.gnu.org>:
ezmlm-reject: fatal: Sorry, I don't accept message with empty Subject (#5.7.0)

--- Below this line is a copy of the message.

Return-Path: <Siu.Bun.Chu@ap.abnamro.com>
Received: (qmail 32647 invoked from network); 27 Nov 1999 03:45:45 -0000
Received: from sg-inet2.ap.abnamro.com (203.127.86.204)
  by sourceware.cygnus.com with SMTP; 27 Nov 1999 03:45:45 -0000
Received: from SGMTA02.ap.abnamro.com ([203.127.86.194])
          by sg-inet2.ap.abnamro.com (Netscape Messaging Server 3.6)
           with SMTP id AAA61B for <gcc@gcc.gnu.org>;
          Sat, 27 Nov 1999 11:54:45 +0800
Received: by SGMTA02.ap.abnamro.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id
48256836.0014C189 ; Sat, 27 Nov 1999 11:46:42 +0800
X-Lotus-FromDomain: ABNAMRO
From: Siu.Bun.Chu@ap.abnamro.com
To: gcc@gcc.gnu.org
Message-ID: <48256836.0014C041.00@SGMTA02.ap.abnamro.com>
Date: Sat, 27 Nov 1999 11:40:00 +0800
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


When I tried to complie the Client.c, an error come out. How can I resolve this

# gcc -o client client.c -lsocket
Undefined                       first referenced
 symbol                             in file
inet_addr                           /var/tmp/cchrLbqU.o  (symbol belongs to impl
icit dependency /usr/lib/libnsl.so.1)
ld: fatal: Symbol referencing errors. No output written to client
collect2: ld returned 1 exit status





I have installed the GCC under \usr\local\bin


Environment :


HOME=/
HZ=100
LOGNAME=root
MAIL=/var/mail/root
PATH=/usr/sbin:/usr/bin
SHELL=/sbin/sh
TERM=vt100
TZ=Hongkong
_INIT_PREV_LEVEL=S
_INIT_RUN_LEVEL=3
_INIT_RUN_NPREV=0
_INIT_UTS_ISA=sparc
_INIT_UTS_MACHINE=sun4m
_INIT_UTS_NODENAME=unix-sparc20
_INIT_UTS_PLATFORM=SUNW,SPARCstation-20
_INIT_UTS_RELEASE=5.7
_INIT_UTS_SYSNAME=SunOS
_INIT_UTS_VERSION=Generic_106541-05
#
_________________________________________________________________________

Disclaimer:

"Any  unauthorized  form of reproduction of this message is strictly prohibited.
The  bank  does  not  guarantee  the  security of any information electronically
transmitted  and  is  not liable for the proper and complete transmission of the
information  contained  in this communication, nor for any delay in its receipt.
THE  USE  OF  EMAIL  FOR  ANY  ILLEGAL  PURPOSE OR FOR ANY PURPOSE OTHER THAN AS
PERMITTED  BY  THE  BANK  IS  STRICTLY  PROHIBITED  AND  SUCH  USE MAY RESULT IN
DISCIPLINARY AND LEGAL ACTION."






_________________________________________________________________________

Disclaimer:

"Any  unauthorized  form of reproduction of this message is strictly prohibited.
The  bank  does  not  guarantee  the  security of any information electronically
transmitted  and  is  not liable for the proper and complete transmission of the
information  contained  in this communication, nor for any delay in its receipt.
THE  USE  OF  EMAIL  FOR  ANY  ILLEGAL  PURPOSE OR FOR ANY PURPOSE OTHER THAN AS
PERMITTED  BY  THE  BANK  IS  STRICTLY  PROHIBITED  AND  SUCH  USE MAY RESULT IN
DISCIPLINARY AND LEGAL ACTION."

Re: failure notice

[Alexandre Oliva]

On Nov 27, 1999, Siu.Bun.Chu@ap.abnamro.com wrote:

> inet_addr                           /var/tmp/cchrLbqU.o  (symbol belongs to implicit dependency /usr/lib/libnsl.so.1)

Please look at the man page of the socket functions you have used in
your program.  It says you must link in `-lsocket -lnsl', not just
`-lsocket'.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: failure notice

[Alexandre Oliva]

On Nov 27, 1999, Siu.Bun.Chu@ap.abnamro.com wrote:

> inet_addr                           /var/tmp/cchrLbqU.o  (symbol belongs to implicit dependency /usr/lib/libnsl.so.1)

Please look at the man page of the socket functions you have used in
your program.  It says you must link in `-lsocket -lnsl', not just
`-lsocket'.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

failure notice

[Siu.Bun.Chu]

---------------------- Forwarded by Siu Bun Chu/HK/ABNAMRO/NL on 27/11/99 11:59
AM ---------------------------


MAILER-DAEMON@sourceware.cygnus.com on 27/11/99 11:45:46 AM

To:   Siu Bun Chu/HK/ABNAMRO/NL@ABNAMRO
cc:
Subject:  failure notice




Hi. This is the qmail-send program at sourceware.cygnus.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<gcc@gcc.gnu.org>:
ezmlm-reject: fatal: Sorry, I don't accept message with empty Subject (#5.7.0)

--- Below this line is a copy of the message.

Return-Path: <Siu.Bun.Chu@ap.abnamro.com>
Received: (qmail 32647 invoked from network); 27 Nov 1999 03:45:45 -0000
Received: from sg-inet2.ap.abnamro.com (203.127.86.204)
  by sourceware.cygnus.com with SMTP; 27 Nov 1999 03:45:45 -0000
Received: from SGMTA02.ap.abnamro.com ([203.127.86.194])
          by sg-inet2.ap.abnamro.com (Netscape Messaging Server 3.6)
           with SMTP id AAA61B for <gcc@gcc.gnu.org>;
          Sat, 27 Nov 1999 11:54:45 +0800
Received: by SGMTA02.ap.abnamro.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id
48256836.0014C189 ; Sat, 27 Nov 1999 11:46:42 +0800
X-Lotus-FromDomain: ABNAMRO
From: Siu.Bun.Chu@ap.abnamro.com
To: gcc@gcc.gnu.org
Message-ID: <48256836.0014C041.00@SGMTA02.ap.abnamro.com>
Date: Sat, 27 Nov 1999 11:40:00 +0800
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


When I tried to complie the Client.c, an error come out. How can I resolve this

# gcc -o client client.c -lsocket
Undefined                       first referenced
 symbol                             in file
inet_addr                           /var/tmp/cchrLbqU.o  (symbol belongs to impl
icit dependency /usr/lib/libnsl.so.1)
ld: fatal: Symbol referencing errors. No output written to client
collect2: ld returned 1 exit status





I have installed the GCC under \usr\local\bin


Environment :


HOME=/
HZ=100
LOGNAME=root
MAIL=/var/mail/root
PATH=/usr/sbin:/usr/bin
SHELL=/sbin/sh
TERM=vt100
TZ=Hongkong
_INIT_PREV_LEVEL=S
_INIT_RUN_LEVEL=3
_INIT_RUN_NPREV=0
_INIT_UTS_ISA=sparc
_INIT_UTS_MACHINE=sun4m
_INIT_UTS_NODENAME=unix-sparc20
_INIT_UTS_PLATFORM=SUNW,SPARCstation-20
_INIT_UTS_RELEASE=5.7
_INIT_UTS_SYSNAME=SunOS
_INIT_UTS_VERSION=Generic_106541-05
#
_________________________________________________________________________

Disclaimer:

"Any  unauthorized  form of reproduction of this message is strictly prohibited.
The  bank  does  not  guarantee  the  security of any information electronically
transmitted  and  is  not liable for the proper and complete transmission of the
information  contained  in this communication, nor for any delay in its receipt.
THE  USE  OF  EMAIL  FOR  ANY  ILLEGAL  PURPOSE OR FOR ANY PURPOSE OTHER THAN AS
PERMITTED  BY  THE  BANK  IS  STRICTLY  PROHIBITED  AND  SUCH  USE MAY RESULT IN
DISCIPLINARY AND LEGAL ACTION."






_________________________________________________________________________

Disclaimer:

"Any  unauthorized  form of reproduction of this message is strictly prohibited.
The  bank  does  not  guarantee  the  security of any information electronically
transmitted  and  is  not liable for the proper and complete transmission of the
information  contained  in this communication, nor for any delay in its receipt.
THE  USE  OF  EMAIL  FOR  ANY  ILLEGAL  PURPOSE OR FOR ANY PURPOSE OTHER THAN AS
PERMITTED  BY  THE  BANK  IS  STRICTLY  PROHIBITED  AND  SUCH  USE MAY RESULT IN
DISCIPLINARY AND LEGAL ACTION."

Re: failure notice

[Timothy J. Wood]

  I'm working on the Quake3:Arena port for MacOS X DP4.  This newly released version supposedly contains a compiler based off of gcc 2.95.2 (at least cc -v claims something to that effect).

  The PPC is really poor at converting ints to floats, there is an optimization problem that is making this even worse.  One of the current hot spots in Quake3:Arena exposes this problem under MacOS X DP4.  I don't have a Linux PPC system to test this on unfortunately (maybe I'll reformat my PowerBook to have more partitions in the future :).

  Some code that demonstrates the problem follows.  I'm using doubles in this code to make the example assembly simpler (avoids rounding the double to a float).

---- cast.c ----

double test1(unsigned short *stuff)
{
    unsigned int i;
    double x = 0;
    for (i = 0; i < 1000; i++)
        x += stuff[i];
    return x;
}


double test2(short *stuff)
{
    unsigned int i;
    double x = 0;
    for (i = 0; i < 1000; i++)
        x += stuff[i];
    return x;
}

double test3(char *stuff)
{
    unsigned int i;
    double x = 0;
    for (i = 0; i < 1000; i++)
        x += stuff[i];
    return x;
}

double test4(unsigned char *stuff)
{
    unsigned int i;
    double x = 0;
    for (i = 0; i < 1000; i++)
        x += stuff[i];
    return x;
}


typedef struct _foo {
    unsigned int i:18;
    unsigned int j:14;
} foo;

double test5(foo *stuff)
{
    unsigned int i;
    double x = 0;
    for (i = 0; i < 1000; i++)
        x += stuff[i].i;
    return x;
}

---- end cast.c ----


  I compile this test case with:

	cc -static -O2 -S cast.c

  (the -static avoids a bunch of Mach-O PIC crud that isn't relevant to the problem), I get something like the following:


.data
.const
        .align 2
LC0:
        .double 0r0.00000000000000000000e0
.text
        .align 2
.globl _test1
_test1:
        lis r7,ha16(LC0)
        la r7,lo16(LC0)(r7)
        lfd f1,0(r7)
        lis r11,0x4330
        lis r9,0x4330
        lis r10,0x8000
        li r8,1000
        mtctr r8
L8:
        lhz r0,0(r3)
        addi r3,r3,2
        stw r9,-16(r1)
        stw r10,-12(r1)
        lfd f13,-16(r1)
        xoris r8,r0,0x8000
        stw r8,-4(r1)
        stw r11,-8(r1)
        lfd f0,-8(r1)
        fsub f0,f0,f13
        fadd f1,f1,f0
        bdnz L8
        blr


  There are two problems here.  First, is that the various constants are duplicated for each function (there are more constants for some of the types).  Maybe the linker cleans this up -- I don't know.

  More important is the second problem.  When building the double on the stack, there are two words, one that is constant throughout the loop and one that needs to be updated for each value.  But, gcc doesn't realize that it can avoid rewriting the constant part of the double on each iteration of the loop and in most of the cases above, ends up issuing twice as many store instructions as necessary.

  But in the case of casting unsigned shorts to floats, gcc goes bonkers and ends up doing part of the conversion twice and throwing away the results.

  Can anyone replicate this result on a PPC Linux box with the latest sources?  Either way, hopefully Apple will be able to fix these problems so that their Quake port for MacOS X will run faster :)

-tim

Re: failure notice

[Masayuki Ida]

re-sending.

 >>Date: 11 Jun 2002 21:12:08 -0000
 >>From: MAILER-DAEMON@sources.redhat.com
 >>
 >>Hi. This is the qmail-send program at sources.redhat.com.
 >> ...
 >>In the meantime, you can add yourself to the gcc.gnu.org
 >> ...
 >>This will enable you to send email without being subjected to
 >>further spam blocking.
 >> 
 >>--- Below this line is a copy of the message.
 >>From: Masayuki Ida <ida@ai.mit.edu>
 >>To: gcc-conf-discuss@gnu.org
 >>CC: gcc@gcc.gnu.org, ida@ai.mit.edu, gcc-sc@goof.com
 >>In-reply-to: <20020611202836.GF9967@ebb.org> (bkuhn@fsf.org)
 >>Subject: Re: Idea for a GCC conference
 >>References:  <20020611202836.GF9967@ebb.org>
 >>
 >> >>Date: Tue, 11 Jun 2002 16:28:36 -0400
 >> >>From: "Bradley M. Kuhn" <bkuhn@fsf.org>
 >>
 >>Thank you Bkuhn,
 >>
 >> >>Masayuki Ida, a Japanese professor who works closely with the FSF, would
 >> >>like to organize a conference focusing on GCC.  As you on this list know,
 >> >>there is a great deal of interest in the compiler, particularly in the
 >> >>embedded community.  It is certainly an important and large enough project
 >> >>that it warrants its own conference.
 >>
 >>I am not an expert of GCC. But I know we are truely relying on the
 >>technology provided by GCC for many aspects. I have been thinking of 
 >>the importance of it and how I can support this with my ability.
 >>It's not the issue on Linux things. It's not the issue on academic 
 >>toys. It's not the issue on just a dream. It's not the issue on 
 >>political game.     For me it's a matter of the creativity of people.
 >>
 >>Also, I found many embedded systems including network equipments
 >>industry, game machine industry, and many other software controlled
 >>something are using GCC as users for their experiments and
 >>sometimes for real products. And most of them have almost
 >>no concerns about kernel.
 >>Some of the random topics they have in their minds are
 >>which CPU chip lines would be good in the future,
 >>how we can improve the performance, And very details on hacks
 >>and mechanisms.
 >>
 >>Unless there is a conference or a workshop FOR GCC,
 >>such engineers can not join and share the meetings,
 >>especially for japanese. Because they are GCC users,
 >>and NOT a part of Linux related, nor a part of language
 >>design,.. they are the GCC users.
 >>I think it is not a special situation for japanese.
 >>It is common on this globe.
 >>Of cause there are many other types of users, and
 >>importantly implementors and designers of the language and
 >>the libraries.
 >>
 >>So, why not have a conferece for GCC?
 >>I have a will and energy to carry out my role, once it is decided.
 >>I need your help and concern.
 >>
 >>Masa Ida
 >>

failure notice

[Andrew Haley]

Using the "send mail to interested parties" link at
http://gcc.gnu.org/cgi-bin/gnatsweb.pl gets me this:

MAILER-DAEMON@sources.redhat.com writes:
 > Hi. This is the qmail-send program at sources.redhat.com.
 > I'm afraid I wasn't able to deliver your message to the following addresses.
 > This is a permanent error; I've given up. Sorry it didn't work out.
 > 
 > <gcc-prs@gcc.gnu.org>:
 > Sender: aph@cambridge.redhat.com
 > This mailing list is not for general discussions.  Please resend your
 > mail note to a more appropriate list.
 > 
 > 
 > <java-prs@gcc.gnu.org>:
 > Sender: aph@cambridge.redhat.com
 > This mailing list is not for general discussions.  Please resend your
 > mail note to a more appropriate list.

What on Earth does this mean?  How should I do this?

Thanks,
Andrew.

Re: failure notice

[Christian Ehrhardt]

On Wed, Jan 08, 2003 at 11:24:23AM +0000, Andrew Haley wrote:
> Using the "send mail to interested parties" link at
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl gets me this:
> 
> MAILER-DAEMON@sources.redhat.com writes:
>  > Hi. This is the qmail-send program at sources.redhat.com.
>  > I'm afraid I wasn't able to deliver your message to the following addresses.
>  > This is a permanent error; I've given up. Sorry it didn't work out.
>  > 
>  > <gcc-prs@gcc.gnu.org>:

Just ignore them or delete gcc-prs from the list of intended recipient.
This is a known problem with GNATS. The message you sent will still
show up in the audit trail after some time if you cc'ed gcc-gnats.

   regards  Christian

-- 
THAT'S ALL FOLKS!

Re: failure notice

[Richard Earnshaw]

> Using the "send mail to interested parties" link at
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl gets me this:
> 
> MAILER-DAEMON@sources.redhat.com writes:
>  > Hi. This is the qmail-send program at sources.redhat.com.
>  > I'm afraid I wasn't able to deliver your message to the following addresses.
>  > This is a permanent error; I've given up. Sorry it didn't work out.
>  > 
>  > <gcc-prs@gcc.gnu.org>:
>  > Sender: aph@cambridge.redhat.com
>  > This mailing list is not for general discussions.  Please resend your
>  > mail note to a more appropriate list.
>  > 
>  > 
>  > <java-prs@gcc.gnu.org>:
>  > Sender: aph@cambridge.redhat.com
>  > This mailing list is not for general discussions.  Please resend your
>  > mail note to a more appropriate list.
> 
> What on Earth does this mean?  How should I do this?
> 

It means that the mailing list reply fields are all screwed up.  You have 
to send messages to gcc-gnats; but the gnats software puts gcc-prs in the 
from field, so automated replies go to the wrong place.... :-(

R.

Re: failure notice

[Joe Buck]

On Wed, Jan 08, 2003 at 11:24:23AM +0000, Andrew Haley wrote:
> Using the "send mail to interested parties" link at
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl gets me this:

[ bounce deleted ]

The "send mail to interested parties" function wants to send mail to the
gcc-prs list (and sometimes java-prs, for Java bugs), but these are
read-only lists.  This is, I believe, a gnatsweb configuration bug,
but in the meantime, I work around the problem by removing the gcc-prs
list from the list of addresses.  As long as gcc-gnats is present and
the subject line doesn't change, your mail will get added to the audit
trail.

Re: failure notice

[Nathanael Nerode]

Using the "send mail to interested parties" link at
http://gcc.gnu.org/cgi-bin/gnatsweb.pl gets me this:

MAILER-DAEMON@sources.redhat.com writes:
 > Hi. This is the qmail-send program at sources.redhat.com.
 > I'm afraid I wasn't able to deliver your message to the following 
addresses.
 > This is a permanent error; I've given up. Sorry it didn't work out.
 > 
 > <gcc-prs@gcc.gnu.org>:
 > Sender: aph@cambridge.redhat.com
 > This mailing list is not for general discussions.  Please resend your
 > mail note to a more appropriate list.
 > 
 > 
 > <java-prs@gcc.gnu.org>:
 > Sender: aph@cambridge.redhat.com
 > This mailing list is not for general discussions.  Please resend your
 > mail note to a more appropriate list.

What on Earth does this mean?  How should I do this?

Thanks,
Andrew.

----
This is a known, and infuriating, bug in GNATSweb.  The '*-prs' mailing 
lists should *not* be in the "send mail to interested parties" list in 
http://gcc.gnu.org/cgi-bin/gnatsweb.pl.  Nobody seems inclined to fix it 
though.

--Nathanael

Re: failure notice

[Falk Hueffner]

Nathanael Nerode <neroden@twcny.rr.com> writes:

> This is a known, and infuriating, bug in GNATSweb.  The '*-prs'
> mailing lists should *not* be in the "send mail to interested
> parties" list in http://gcc.gnu.org/cgi-bin/gnatsweb.pl.  Nobody
> seems inclined to fix it though.

Ah, is that nobody@gcc.gnu.org who also get mentioned in the "intested
parties"? ;)

-- 
	Falk

Re: failure notice

[Michael S. Zick]

On Wednesday 08 January 2003 06:26 am, Falk Hueffner wrote:
> Nathanael Nerode <neroden@twcny.rr.com> writes:
> > This is a known, and infuriating, bug in GNATSweb.  The '*-prs'
> > mailing lists should *not* be in the "send mail to interested
> > parties" list in http://gcc.gnu.org/cgi-bin/gnatsweb.pl.  Nobody
> > seems inclined to fix it though.
>
> Ah, is that nobody@gcc.gnu.org who also get mentioned in the "intested
> parties"? ;)

I think that is the address of the person in-charge of design planning and
implementation strategy studies.

Mike

Re: failure notice

[G Shyam Sundar]

Hi,
   I am working with a kernel module, which was compiled using GCC
4.X, for x86_64 platform.
   After dis-assembling the module object file, I see that the callq
function is always called with the next instruction of the code as the
target address(based on IP only), as the offset feild following the
instruction "e8"(corresponding to callq) is always 0, instead of the
address of the function where I would think the call should be
actually made to.
   What I want to understand is, how function calls work here? Based
on my understanding, the callq instruction should be followed by a
offset address, so that RIP = RIP + Offset. The offset in my case is
always 0. For the following code, the actual address where
qla2xxx_wake_dpc(pha) starts from is 0x1ac68
C Code:
qla2x00_timer{
                    .....
                    .....
                    test_bit(RELOGIN_NEEDED, &ha->dpc_flags)))
                               qla2xxx_wake_dpc(pha);
       qla2x00_restart_timer(ha, WATCH_INTERVAL);
}

Disassembly:
0x000000000001df91 <qla2x00_timer+833>: test $200000,%eax
0x000000000001df96 <qla2x00_timer+838>: je 0x1dfa0
0x000000000001df98 <qla2x00_timer+840>: mov %r15,%rdi
0x000000000001df9b <qla2x00_timer+843>: callq 0x1dfa0
0x000000000001dfa0 <qla2x00_timer+848>: mov 0(%rip),%rsi
0x000000000001dfa7 <qla2x00_timer+855>: lea 0x2288(%r12),%rdi
0x000000000001dfaf <qla2x00_timer+863>: add $0x64,%rsi
0x000000000001dfb3 <qla2x00_timer+867>: callq 0x1dfb8
0x000000000001dfb8 <qla2x00_timer+872>: add $0x8,%rsp
0x000000000001dfbc <qla2x00_timer+876>: pop %rbx
0x000000000001dfbd <qla2x00_timer+877>: pop %r12
0x000000000001dfbf <qla2x00_timer+879>: pop %r13
0x000000000001dfc1 <qla2x00_timer+881>: pop %r14
0x000000000001dfc3 <qla2x00_timer+883>: pop %r15
0x000000000001dfc5 <qla2x00_timer+885>: leaveq
0x000000000001dfc6 <qla2x00_timer+886>: retq

Hexdump starting 0x1df98:
4c 89 ff
e8 00 00 00 00
48 8b 35 00 00 00 00
49 8d bc 24 88 22 00 00
48 83 c6 64
e8 00 00 00 00
I am not sure if this is the right list for this query. Please point
me to the right one if this is not.
Thanks
Shyam

RE: failure notice

[Dave Korn]

G Shyam Sundar wrote on 30 July 2008 10:24:

>    What I want to understand is, how function calls work here? 

  Google "linking".

> I am not sure if this is the right list for this query. Please point
> me to the right one if this is not.

  This is a binutils question really.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: failure notice

[Andrew Haley]

G Shyam Sundar wrote:
> Hi,
>    I am working with a kernel module, which was compiled using GCC
> 4.X, for x86_64 platform.
>    After dis-assembling the module object file, I see that the callq
> function is always called with the next instruction of the code as the
> target address(based on IP only), as the offset feild following the
> instruction "e8"(corresponding to callq) is always 0, instead of the
> address of the function where I would think the call should be
> actually made to.

Use "objdump --reloc"

Andrew.

Re: failure notice

[niXman]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Diffs between stage2 and stage3.

on configure libiberty for stage3 I see this warnings:

configure:4962: checking for limits.h
configure:4962:  /home/root/gcc-build/build/gcc-trunk/./prev-gcc/xgcc
-B/home/root/gcc-build/build/gcc-trunk/./prev-gcc/
-B/usr/local/i686-pc-openbsd5.0/bin/
-B/usr/local/i686-pc-openbsd5.0/bin/
-B/usr/local/i686-pc-openbsd5.0/lib/ -isystem
/usr/local/i686-pc-openbsd5.0/include -isystem
/usr/local/i686-pc-openbsd5.0/sys-include    -E  conftest.c
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:
symbol(_ZNSt6locale5_Impl11_S_id_ctypeE) size mismatch, relink your
program
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:
symbol(_ZNSt6locale5_Impl13_S_id_numericE) size mismatch, relink your
program
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:
symbol(_ZNSt6locale5_Impl13_S_id_collateE) size mismatch, relink your
program
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:
symbol(_ZNSt6locale5_Impl10_S_id_timeE) size mismatch, relink your
program
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:
symbol(_ZNSt6locale5_Impl14_S_id_monetaryE) size mismatch, relink your
program
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:
/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:
symbol(_ZNSt6locale5_Impl14_S_id_messagesE) size mismatch, relink your
program

I have never seen such warnings...
Therefore, some tests fail.

[-- Attachment #2: config.h.diff --]
[-- Type: text/x-patch, Size: 5393 bytes --]

--- /home/nixman/config_correct.h
+++ /home/nixman/config_incorrect.h
@@ -54,7 +54,7 @@
 #define HAVE_DECL_CALLOC 1
 
 /* Define to 1 if you have the declaration of `ffs', and to 0 if you don't. */
-#define HAVE_DECL_FFS 1
+#define HAVE_DECL_FFS 0
 
 /* Define to 1 if you have the declaration of `getenv', and to 0 if you don't.
    */
@@ -74,7 +74,7 @@
 
 /* Define to 1 if you have the declaration of `sbrk', and to 0 if you don't.
    */
-#define HAVE_DECL_SBRK 1
+#define HAVE_DECL_SBRK 0
 
 /* Define to 1 if you have the declaration of `snprintf', and to 0 if you
    don't. */
@@ -96,7 +96,7 @@
 /* #undef HAVE_DUP3 */
 
 /* Define to 1 if you have the <fcntl.h> header file. */
-#define HAVE_FCNTL_H 1
+/* #undef HAVE_FCNTL_H */
 
 /* Define to 1 if you have the `ffs' function. */
 #define HAVE_FFS 1
@@ -129,13 +129,13 @@
 #define HAVE_INSQUE 1
 
 /* Define to 1 if the system has the type `intptr_t'. */
-#define HAVE_INTPTR_T 1
+/* #undef HAVE_INTPTR_T */
 
 /* Define to 1 if you have the <inttypes.h> header file. */
-#define HAVE_INTTYPES_H 1
+/* #undef HAVE_INTTYPES_H */
 
 /* Define to 1 if you have the <limits.h> header file. */
-#define HAVE_LIMITS_H 1
+/* #undef HAVE_LIMITS_H */
 
 /* Define to 1 if you have the <machine/hal_sysinfo.h> header file. */
 /* #undef HAVE_MACHINE_HAL_SYSINFO_H */
@@ -159,7 +159,7 @@
 #define HAVE_MEMMOVE 1
 
 /* Define to 1 if you have the <memory.h> header file. */
-#define HAVE_MEMORY_H 1
+/* #undef HAVE_MEMORY_H */
 
 /* Define to 1 if you have the `memset' function. */
 #define HAVE_MEMSET 1
@@ -225,13 +225,13 @@
 /* #undef HAVE_SPAWNVPE */
 
 /* Define to 1 if you have the <stdint.h> header file. */
-#define HAVE_STDINT_H 1
+/* #undef HAVE_STDINT_H */
 
 /* Define to 1 if you have the <stdio_ext.h> header file. */
 /* #undef HAVE_STDIO_EXT_H */
 
 /* Define to 1 if you have the <stdlib.h> header file. */
-#define HAVE_STDLIB_H 1
+/* #undef HAVE_STDLIB_H */
 
 /* Define to 1 if you have the `stpcpy' function. */
 /* #undef HAVE_STPCPY */
@@ -252,10 +252,10 @@
 #define HAVE_STRERROR 1
 
 /* Define to 1 if you have the <strings.h> header file. */
-#define HAVE_STRINGS_H 1
+/* #undef HAVE_STRINGS_H */
 
 /* Define to 1 if you have the <string.h> header file. */
-#define HAVE_STRING_H 1
+/* #undef HAVE_STRING_H */
 
 /* Define to 1 if you have the `strncasecmp' function. */
 #define HAVE_STRNCASECMP 1
@@ -297,16 +297,16 @@
 #define HAVE_SYS_ERRLIST 1
 
 /* Define to 1 if you have the <sys/file.h> header file. */
-#define HAVE_SYS_FILE_H 1
+/* #undef HAVE_SYS_FILE_H */
 
 /* Define to 1 if you have the <sys/mman.h> header file. */
-#define HAVE_SYS_MMAN_H 1
+/* #undef HAVE_SYS_MMAN_H */
 
 /* Define if you have the sys_nerr variable. */
 #define HAVE_SYS_NERR 1
 
 /* Define to 1 if you have the <sys/param.h> header file. */
-#define HAVE_SYS_PARAM_H 1
+/* #undef HAVE_SYS_PARAM_H */
 
 /* Define to 1 if you have the <sys/prctl.h> header file. */
 /* #undef HAVE_SYS_PRCTL_H */
@@ -315,16 +315,16 @@
 /* #undef HAVE_SYS_PSTAT_H */
 
 /* Define to 1 if you have the <sys/resource.h> header file. */
-#define HAVE_SYS_RESOURCE_H 1
+/* #undef HAVE_SYS_RESOURCE_H */
 
 /* Define if you have the sys_siglist variable. */
 #define HAVE_SYS_SIGLIST 1
 
 /* Define to 1 if you have the <sys/stat.h> header file. */
-#define HAVE_SYS_STAT_H 1
+/* #undef HAVE_SYS_STAT_H */
 
 /* Define to 1 if you have the <sys/sysctl.h> header file. */
-#define HAVE_SYS_SYSCTL_H 1
+/* #undef HAVE_SYS_SYSCTL_H */
 
 /* Define to 1 if you have the <sys/sysinfo.h> header file. */
 /* #undef HAVE_SYS_SYSINFO_H */
@@ -339,10 +339,10 @@
 /* #undef HAVE_SYS_TABLE_H */
 
 /* Define to 1 if you have the <sys/time.h> header file. */
-#define HAVE_SYS_TIME_H 1
+/* #undef HAVE_SYS_TIME_H */
 
 /* Define to 1 if you have the <sys/types.h> header file. */
-#define HAVE_SYS_TYPES_H 1
+/* #undef HAVE_SYS_TYPES_H */
 
 /* Define to 1 if you have <sys/wait.h> that is POSIX.1 compatible. */
 #define HAVE_SYS_WAIT_H 1
@@ -354,7 +354,7 @@
 #define HAVE_TIMES 1
 
 /* Define to 1 if you have the <time.h> header file. */
-#define HAVE_TIME_H 1
+/* #undef HAVE_TIME_H */
 
 /* Define to 1 if you have the `tmpnam' function. */
 #define HAVE_TMPNAM 1
@@ -363,7 +363,7 @@
 #define HAVE_UINTPTR_T 1
 
 /* Define to 1 if you have the <unistd.h> header file. */
-#define HAVE_UNISTD_H 1
+/* #undef HAVE_UNISTD_H */
 
 /* Define to 1 if you have the `vasprintf' function. */
 #define HAVE_VASPRINTF 1
@@ -450,7 +450,7 @@
 #define TIME_WITH_SYS_TIME 1
 
 /* Define to an unsigned 64-bit type available in the compiler. */
-#define UNSIGNED_64BIT_TYPE uint64_t
+#define UNSIGNED_64BIT_TYPE unsigned long long
 
 /* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
    significant byte first (like Motorola and SPARC, unlike Intel). */
@@ -481,7 +481,7 @@
 
 /* Define to the type of a signed integer type wide enough to hold a pointer,
    if such a type exists, and if the system does not define it. */
-/* #undef intptr_t */
+#define intptr_t int
 
 /* Define to `int' if <sys/types.h> does not define. */
 /* #undef pid_t */
@@ -491,7 +491,7 @@
 
 /* Define to the type of an unsigned integer type wide enough to hold a
    pointer, if such a type exists, and if the system does not define it. */
-/* #undef uintptr_t */
+#define uintptr_t unsigned int
 
 /* Define as `fork' if `vfork' does not work. */
 /* #undef vfork */

[-- Attachment #3: config.log.diff.tar.gz --]
[-- Type: application/x-gzip, Size: 15704 bytes --]