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: 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: 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:

[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

No Subject

[cmars]

------
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

[@ 2000-04-19 2:59 UTC (permalink / raw)]

No Subject

[@ 2000-04-01 0:00 UTC (permalink / raw)]

No Subject

[Vincent Habart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 46 bytes --]

unsubscribe  vincent.habart@libertysurf.fr

No Subject

[mzlai]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

  I want to build a cross-compiler in a emebded system 
with a CPU of  ARM and without  the support of any OS lib.
     Now,I got a shell program "bit_ada" in my hand and  It
 has been used to build a cross-compiler in the i386 rtems
 system.  I want to use the shell program just mentioned above 
and make some changes to it. But I don't know whether it is going to work or how to make the little changes to it. I am very appreciated
 for the advices from the wiser or the experts in this field!

Thanks!

_____________________________________________
Ê׶¼ÔÚÏß--ÏȽøÖйúÈ˵ÄÍøÉϼÒÔ° http://www.263.net
Ãâ·ÑÓÊÏä ÓʼþÔÓÖ¾ Ç©ÃûÓʼþ Óʼþ¼ÓÃÜ Óʼþ×·Éíºô
ËÑË÷ÒýÇæ ¸öÈËÕ¾µã ÔÚÏßÓÎÏ· ÍøÉÏÁÄÌì ÍøÉϹҺÅ
½ðÈÚÍõ¹ú ÔÚÏßɱ¶¾ ÌøÔéÊг¡ Èí¼þÏÂÔØ ÐÝÏÐÓéÀÖ

_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.

No Subject

[Langerholc, Larry]

I've lost my bookmarks for Netscape. Could someone e-mail me the URL for the
crosgcc archives that are in HTML format?

Thanks,


Larry Langerholc (561)-997-3789
e-mail: larry.langerholc@icn.siemens.com



_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.

No Subject

[Robert J. Brown]

>>>>> "Larry" == Langerholc, Larry <Larry.Langerholc@icn.siemens.com> writes:

    Larry> I've lost my bookmarks for Netscape. Could someone e-mail
    Larry> me the URL for the crosgcc archives that are in HTML
    Larry> format?

http://www.elilabs.com/xgccarc

-- 
--------  "And there came a writing to him from Elijah"  [2Ch 21:12]  --------
R. J. Brown III  rj@elilabs.com http://www.elilabs.com/~rj  voice 847 543-4060
Elijah Laboratories Inc. 457 Signal Lane, Grayslake IL 60030  fax 847 543-4061
-----  M o d e l i n g   t h e   M e t h o d s   o f   t h e   M i n d  ------
_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.

No Subject

[Tom Sys]

subscribe
_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.

No Subject

[Paul Carpenter]

subscribe


_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.

No Subject

[No]

Sorry, but I have no idea what you're referring to when you say "CYGNUS 
LOCAL".  I don't recall anything about it in the FAQ (oddly enough I did 
just see a message on the egcs list talking about "CYGNUS LOCAL" wrt 
java, but I still didn't understand what it meant).

All I know is, when I asked last February about elf for m68k, Mark 
Phillips was the only one who offered patches.  When I asked on the egcs 
list this summer (being surprised that there still was no m68k-elf 
support), I was told by Jeffrey Law (who I believe works for Cygnus) 
that no one had submitted patches, that I could send in Mark Phillips's 
patches, but they'd probably have to get him to assign the patches to 
the FSF before they could include them.  If Cygnus has m68k-elf patches, 
I have no idea why those can't be put in egcs.
--
John A. Breen
jab3@hotmail.com


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
________________________________________________
To get help for the crossgcc list, send mail to
crossgcc-request@cygnus.com with the text 'help'
(without the quotes) in the body of the message.

No Subject

[No]

That's the way we used to do it, but it seemed "inelegant".  Directly 
linking in the configuration data seemed much more direct.  Having to 
put something in the linker command file didn't bother me, since the 
command file is specific to this board anyway.  But as it stands, I have 
to translate the ascii hex to binary, use objcopy to embed the binary in 
an existing object file, and save it as a second object file.  
Translating to C is starting to sound better again.  Of course, now I'll 
have the original hex data file, the .c file, and a .o file.  Either 
way, it's not as direct as I'd originally hoped.

BTW, the reason I want it linked with the executable is that each 
executable may have a different configuration for the FPGA, depending on 
the application.  This way, we don't have to worry about the program and 
the configuration data getting mismatched.
--
John A. Breen
jab3@hotmail.com


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
=========================================================
To get command help for the crossgcc list, including help
on adding/removing yourself to/from the list, send e-mail
to majordomo@cygnus.com with the text 'help' (without the
quotes) in the body of the message.
=========================================================

No Subject

[No]

>I'm not too sure if this is the most afficient way, as I'm a crossgcc
>newbie by myself, but from my point of view I'd define an extra
>section for this (for example .fpgadata) as follows:
>
> [linker file snipped]
>

Your example worked pretty much as is.  It turns out that the difficult 
part (which I thought would be easy) is using objcopy.  It apparently 
won't directly convert an S-record file (or any format I could get the 
data file into) to elf.  In fact, I can't even convert from srec to 
binary; it gives me the error:

    Warning: Output file cannot represent architecture UNKNOWN!

Anyone understand what this is saying?  My "architecture" (as far as 
what binutils was built for) is m68k-elf, but I don't think that's what 
it means (even if it is, I can't see a way to specify it).

The other problem (which I could get around if I could convert srec to 
binary) is that the only way to create a new section with objcopy is to 
use --add-section, which takes a separate file argument and copies the 
whole file into the section, without translation.

Anyone have any suggestions on this end of things?  I know I can use 
scripts and such to do the translation, but I wanted to do it with the 
"standard" tools if possible (I also wanted to cut down on the number of 
intermediate files).
--
John A. Breen
jab3@hotmail.com


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
=========================================================
To get command help for the crossgcc list, including help
on adding/removing yourself to/from the list, send e-mail
to majordomo@cygnus.com with the text 'help' (without the
quotes) in the body of the message.
=========================================================

No Subject

[No]

You mean for gcc-2.7.2.2?  Yes, I have them on my web page (with the 
author's permission).  Look at

  http://home.worldnet.att.net/~jabberwock82/crossgcc/

(Note there's a typo in the page: m69k should obviously be m68k; gotta 
fix that some day.)  Some of the patch has to do with adding a -mcpu32 
switch, which is apparently already in egcs.

I don't have the headers for egcs publicly available; the development 
team has agreed to put in the gcc-2.7.2.2 patch, and they'll probably do 
a better job than I did upgrading it to egcs.

>> Then, when it got to libf2c (which I don't even want, but can't
>>figure out how to get rid of), it decided that it needed crt0.o.
>
> This is the last job to do when building egcs-1.1a...
>
> When the job is over and everything you need is ready, why to worry
> about things you don't even need?

I hate to have installations die in the middle, since I'm never sure how 
much more they have to do.  Since I'd never gotten through a complete 
build, I didn't know if it was the last thing.

> Your real problems lay in how well you managed to fix the
> 'gcc/config/m68k' config files... 

It appeared that the gcc-2.7.2.2 patch was mostly some modifications to 
gcc/config/m68k/coff.h.  Using it as a guide, I made essentially the 
same mods to the egcs coff.h (although there were a few differences, 
like ASM_OUTPUT_SECTION).

> It could be useful to compare our 'fixed' config files for
>'m68k-elf'...

Feel free to look at the links above.  Like I said, I didn't write them 
:).
--
John A. Breen
jab3@hotmail.com


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
=========================================================
To get command help for the crossgcc list, including help
on adding/removing yourself to/from the list, send e-mail
to majordomo@cygnus.com with the text 'help' (without the
quotes) in the body of the message.
=========================================================

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

No Subject

[Jerry Hicks]

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

 sincerely yours
 chenggang Duan


Hi!

Around here we would install binutils from ftp://prep.ai.mit.edu/pub/gnu/
and use m68k-coff-objcopy   ;-)

Good Luck,

Jerry Hicks
jerry.hicks@glenayre.com

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

No Subject

[No]

>I'm surprised here, because newlib-1.7.1/newlib/libc/stdlib/rand.c 
>does
[not?]
>appear to reference sbrk (or any other function).


It appears to have something to do with "impure pointers", which is 
apparently needed by newlib's reeentrant stuff.  It also appears that 
newlib's rand() only returns a 15-bit result, so I think I'll write my 
own anyway.

>I had to hack the compiler to build m68k-elf which generates

>ELF/DWARF files.


So I take it 2.7.2.x doesn't support elf directly (I couldn't remember).  
What about the latest version of gcc?  Or does it need even more 
patches?

Thanks.
--
John A. Breen
jab3@hotmail.com


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

No Subject

[baumann]

list
_________________________________________________________________
Hj. Baumann, Neu-Technikum Buchs, CH 9470 Buchs, Switzerland
Mail: baumann@ntb.ch, Tel: +41 81 755 3381, Fax: +41 81 756 5434

No Subject

[Romain Kobylanski]

suscribe