No Subject

No Subject

[Pete Popov]

Hi,

I'm using a mips64 dos-hosted cross
compiler which I built on my Linux box.
The compiler has been working fine and
we haven't ran into any problems, but
there's something I don't understand and
it really frustrates me.

I'm compiling all files with "-nostdinc"
switch; the files are later linked with
"-nostdlib".   I've got my own version
of "memcpy" and a few other routines;
however, for some reason, the compiler
chooses to insert the standard libc
memcpy in some of the files.  Thus, some
files get my version of memcpy, and
other get the libc version.  There's is
no apparent difference in those files;
they include the same .h files, they are
compiled with the same switches, etc.
Any suggestions?

Thanks,

Pete

Re: your mail

[Rolf Fiedler]

On Tue, 19 May 1998, Pete Popov wrote:
> 
> Hi,
> 
> I'm using a mips64 dos-hosted cross
> compiler which I built on my Linux box.
> The compiler has been working fine and
> we haven't ran into any problems, but
> there's something I don't understand and
> it really frustrates me.
> 
> I'm compiling all files with "-nostdinc"
> switch; the files are later linked with
> "-nostdlib".   I've got my own version
> of "memcpy" and a few other routines;
> however, for some reason, the compiler
> chooses to insert the standard libc
> memcpy in some of the files.  Thus, some
> files get my version of memcpy, and
> other get the libc version.  There's is
> no apparent difference in those files;
> they include the same .h files, they are
> compiled with the same switches, etc.
> Any suggestions?

the compiler is not linking in anything from the libc, but it has builtin
functions for some very common functions. when you initialize an
array (or any other datastructure) the compiler needs to have a bcopy or
memcopy. So if the
compiler already has a target-optimized memcpy, why not use it for 
libc memcpy calls as well?
if you do not like this behaviour, turn it off using -fno-builtin

       -fno-builtin
              Don't recognize built-in functions that do not  be-
              gin  with  two leading underscores.  Currently, the
              functions affected include _exit, abort, abs, allo-
              ca,  cos,  exit,  fabs,  labs, memcmp, memcpy, sin,
              sqrt, strcmp, strcpy, and strlen.

              The `-ansi' option prevents alloca and  _exit  from
              being builtin functions.

> 
> Thanks,
> 
> Pete
> 
you're welcome
rolf

+-----------------+-----------------------------------------+
|    _____        |  Rolf Fiedler                           |
|   / ___/        |  Electronic Design Engineer             |
|  / _/           |  Ferrari electronic GmbH                |
| /_/e/r/r/a/r/i/ |  phone: +49 3328 4559 0                 |
|   electronic    |  E-Mail: Rolf.Fiedler@Ferrari.DE        |
|                 |  fax  : +49 3328 4559 60                |
+-----------------+-----------------------------------------+
           "Where do you want to go tomorrow?"

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: GaA0Lt9cAkyY3fgatYUx2tjteW8lyG8I

iQA/AwUANWKTuYCk3bE/FtS8EQL4NQCggaptQ5tuhxpc1+U1KfFTwVGCQxgAoMHQ
hX9QONTl3J1hhlfRX6LjID58
=a2W/
-----END PGP SIGNATURE-----

Re: memcpy

[Jonathan Larmour]

Pete Popov wrote:
[snip 8< ]
> I've got my own version
> of "memcpy" and a few other routines;
> however, for some reason, the compiler
> chooses to insert the standard libc
> memcpy in some of the files.  Thus, some
> files get my version of memcpy, and
> other get the libc version.

I don't think its actually the libc version that's being included. If you
look at the man page for gcc you will find that gcc itself provides builtin
versions of _exit, abort, abs, alloca, cos, exit, fabs, labs, memcmp,
memcpy, sin, sqrt, strcmp, strcpy, and strlen.

To avoid this behaviour try either -fno-builtins or -mmemcpy (I haven't
tried these though so YMMV).

Jonathan L.
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"It is impossible to enjoy idling thoroughly unless||Home e-mail: jifl @ 
one has plenty of work to do - Jerome K. Jerome"   ||     jifvik.demon.co.uk
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re:

[Pete Popov]

Thanks to everyone who responded to my
mail.  I now understand the "problem" and
know how to fix it.

Thanks again,

Pete

Pete Popov wrote:

> Hi,
>
> I'm using a mips64 dos-hosted cross
> compiler which I built on my Linux box.
> The compiler has been working fine and
> we haven't ran into any problems, but
> there's something I don't understand and
> it really frustrates me.
>
> I'm compiling all files with "-nostdinc"
> switch; the files are later linked with
> "-nostdlib".   I've got my own version
> of "memcpy" and a few other routines;
> however, for some reason, the compiler
> chooses to insert the standard libc
> memcpy in some of the files.  Thus, some
> files get my version of memcpy, and
> other get the libc version.  There's is
> no apparent difference in those files;
> they include the same .h files, they are
> compiled with the same switches, etc.
> Any suggestions?
>
> Thanks,
>
> Pete

Re: your mail

[Chris Jones]

subscribe

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com

Re: your mail

[Michael Matz]

Hi,

On Mon, 23 Feb 2004, kripa shankar wrote:

> ;; Start of basic block 2, registers live: 11 [fp] 13 [sp]
> (note 62 41 45 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (insn 45 62 46 (set (reg/i:SI 0 r0)        (const_int 0 [0x0])) 176 {*movsi_insn} (nil)    (expr_list:REG_EQUAL (const_int 0 [0x0])        (nil)))
> (insn 46 45 76 (use (reg/i:SI 0 r0)) -1 (insn_list 45 (nil))    (nil))
> (insn 76 46 77 (set (reg:SI 7 r7)        (plus:SI (reg:SI 5 r5)            (const_int 2 [0x2]))) -1 (nil)    (nil))
> (insn 77 76 50 (set (reg:SI 6 r6)        (plus:SI (reg:SI 4 r4)            (const_int 2 [0x2]))) -1 (nil)    (nil))
> ;; End of basic block 2
> (note 50 77 63 0 NOTE_INSN_BLOCK_END)
> (note 63 50 0 "" NOTE_INSN_DELETED)
> 
> The instructions inserted are r7 = r5 + 2;r6 = r4 + 2; But the problem
> is that the inserted instructions are not present in both asm file
> (fourth.s) and the output binary file (fourth.o).. I have inserted these
> instructions right after all the optimization passess and before the
> final pass (final.c) where RTL gets converted into Assembly. Kindly help
> me.

There is not enough information.  Where exactly have you added the code to
add those insns?  About which compiler version do you speak?  Produce all 
dump files (-da) and look which dump misses them first.  The problem is, 
that you include those instructions without updating lifeness (i.e. the 
compiler doesn't see, that r6 and r7 really are required after you've set 
them.  So, if there is any pass deleting useless insns after you inserted 
them, they will get deleted.


Ciao,
Michael.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com

No Subject

[Duan, Chenggang (Chenggang)]

Does someone have ddump to convert m68k-coff
 format into Motorola S_records?
 Thanx in advance.

 sincerely yours
 chenggang Duan

Re: your mail

[joel]

On Mon, 7 Sep 1998, Duan, Chenggang (Chenggang) wrote:

> Does someone have ddump to convert m68k-coff
>  format into Motorola S_records?

You should have everything already to do this.  Try this command:

m68k-coff-objdump -O srec FILE.coff -o FILE.srec

Good Luck.

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985

Re: your mail

[Harry G. Clayton]

> 
> Does someone have ddump to convert m68k-coff
>  format into Motorola S_records?
>  Thanx in advance.
> 
>  sincerely yours
>  chenggang Duan
> 

See the man page or info for 'objcopy' from the binutils package.  It
can convert m68k-coff to S-records.

If I remember correctly, you can configure binutils --with-targets=ALL
(or something similar, see the various README/INSTALLs in binutils)
and then objcopy can convert anything to anything.  (except that you
won't benifit from converting binary or S-records to ELF for obvious
reasons.  Rule of thumb, always convert from the most verbose object
format to the least verbose.)

-- 
-hgc
  Harry G. Clayton     hgc@symuli.com      HClayton@SaharaNet.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Support the anti-Spam amendment ---> Join at http://www.cauce.org/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Most widely published lie: 'Installation is the reverse of disassembly'

Re: your mail

[joel]

On Tue, 8 Sep 1998, Harry G. Clayton wrote:

> If I remember correctly, you can configure binutils --with-targets=ALL
> (or something similar, see the various README/INSTALLs in binutils)
> and then objcopy can convert anything to anything.  (except that you
> won't benifit from converting binary or S-records to ELF for obvious
> reasons.  Rule of thumb, always convert from the most verbose object
> format to the least verbose.)

There are limits to what the object format conversion can do particularly
with debug information BUT it does work amazingly well on lots of cases.

I think Srecords are always included in the list of supported formats.

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985

No Subject

[Tan Pinghui]

Hello,

I compiled the tool chain of binutils-2.7, gcc-2.7.2.1, newlib-1.8.0,
gdb-4.16 to do Linux to i386-coff cross-development, the tool building
process is successful. My host environment is a linux 2.0.30, target
machine is a 386 PC without OS support. The target use the RS-232 port
to input/output data.

Some strange behaviors occur with the following simple program, I
can't figure out why and how.

---------------------------------------------------
#include <stdio.h>
int main(void)
{
    char name[100];
    
    while (1) {
          printf("Enter your name: ");
          gets(name);
          printf("Hello, %s!\n", name);
    }

    return 0;
}
---------------------------------------------------

The terminal screen snapshot is:
---------------------------------------------------
Enter your name: Hello, ABCD!
Enter your name: Hello, ABCD!
Enter your name: Hello, ABCD!
Enter your name: Hello, ABCD!
....
---------------------------------------------------


After printing the first "Enter your name: ", the program stoped to
wait for the input, that's right. I entered "ABCD<CR>".

What strange is:
(1) It didn't echo my input to the terminal
(2) It didn't go to the next printf statement but continued to
    wait for the input
(3) I entered a second <CR>, it didn't go but fly.  The program
    kept printing "Enter your name: Hello, ABCD!" and didn't stop
    to wait for further input.

I've tried newlib-1.7.0 also, but the result is same. The crt0 and
libgloss routines are correct I think, what's the matter?

Best regards,
 Tan Pinghui                        mailto:tanph@bj.col.com.cn

Re: your mail

[Hans Zuidam]

> Tan Pinghui wrote:
> Some strange behaviors occur with the following simple program, I
> can't figure out why and how.
Although I don't know your hardware setup it looks like gets() is
returning EOF on the second call to it, gets() should return a
nil-string.  The subtle difference is that gets() should return a
nil-string (i.e. "") if you only type a newline and it should return
a NULL pointer to signal EOF or a read error.  Try the same program
on any UNIX box and type ^D (EOF) on the second gets().  Hope this
helps,
					Hans

-- 
H. Zuidam                        E-Mail: hans@brandinnovators.com
Brand Innovators B.V.            P-Mail: P.O. Box 1377
de Pinckart 54                   5602 BJ Eindhoven, The Netherlands
5674 CC Nuenen                   Tel. +31 40 2631134, Fax. +31 40 2831138