Where are _modsi3.c and/or _modsi3.o?

Where are _modsi3.c and/or _modsi3.o?

[Christopher Bahns]

I built binutils/gcc/newlib on my machine (Windows 98/NT, for m68k-coff
target), and things are basically going ok, but I'm having trouble with
the mod ('%') operator. I looked at the assembly language output and see
that it has a 'jsr __modsi3'. I check the map file and find the
'__modsi3' routine as follows:

 .text          0x00008c9c       x2e
/gcc-m68k/lib/gcc-lib/m68k-coff/2.95.2/libgcc.a(_modsi3.o)
                0x00008c9c                __modsi3

I extracted the source but could not find a file that fit the '_mod*' or
'_mod*.*' patterns, using both the Cygwin/Unix 'find' command and
Microsoft Explorer's find program. I re-built the compiler and also
could find no such object file in the build directory. I'd like to look
at the source code to find out if the arguments are being passed
properly.

I can send more details about my original problem with the mod operator
if you like. I have a very simple program that just does not work right.
If I use a different mathematics operator ('/', '*', etc.) then it's
fine. Also, the same code works perfectly if built with the Microtek
Research (MRI) compiler. If I can solve that problem then perhaps I
don't need to find _modsi3.c/o.

Can anyone help on where to find the code for the __modsi3 function?

Bonus question:
Is there a GCC option to generate an assembly listing without affecting
the build process. I know about the '-S' option, which generates
assembly code INSTEAD of object code (unless I'm just not using it
right). What I want is to generate assembly code IN ADDITION to object
code, and have the compilation process otherwise complete normally. I'd
like to specify a separate directory for the assembly listings and have
them all go there. This way, if I later have trouble and want to know
how a library routine works, I can just look it up instead of rebuilding
the whole damn thing again.

Thanks a lot for any help!
Christopher Bahns
Christopher Bahns Software

Re: Where are _modsi3.c and/or _modsi3.o?

[Jeff Bevis]

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

At 06:16 PM 6/24/00 -0500, Christopher Bahns wrote:
Can anyone help on where to find the code for
the __modsi3 function?
We are having the same kinds of problems here with the powerpc cross
compiler.  Math functions are poorly (if at all) documented, I am
afraid.  If someone can point to a good reference, I would be very
grateful.  We're about to embark on the construction of a FP math
emulation library, and I honestly have no idea where to start on that
yet.  It does not appear to be part of newlib :^(  However, I
have digressed...

Bonus question:
Is there a GCC option to generate an assembly listing without
affecting
the build process. I know about the '-S' option, which generates
assembly code INSTEAD of object code (unless I'm just not using it
right).
YES!  Here's something cut from our makefiles:

         $(CC)
-S $(CC_OPTS) -o $(DIR_ASM)/$*.$(SUFFIX_ASM) $<
         $(AS) -X
$(AS_OPTS) -o $@ $(DIR_ASM)/$*.$(SUFFIX_ASM)
-alh=$(DIR_LISTING)/$*.$(SUFFIX_ASM_LISTING)

The important part you're interested in is the
"-alh=listing_file_name.  I think this should be pretty
self-explanatory with the macros not expanded, let me know if not.




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

Re: Where are _modsi3.c and/or _modsi3.o?

[Doug Evans]

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

Jeff Bevis writes:
 > We are having the same kinds of problems here with the powerpc cross
 > compiler.  Math functions are poorly (if at all) documented, I am afraid.
 > If someone can point to a good reference, I would be very grateful.  We're about
 > to embark on the construction of a FP math emulation library, and I honestly
 > have no idea where to start on that yet.  It does not appear to be part of newlib :^(

It's not supposed to be part of newlib.
It's part of libgcc.  See, for example, gcc/config/fp-bit.c.
I see fp-bit.c mentioned in several t-* files in gcc/config/rs6000.


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

Re: Where are _modsi3.c and/or _modsi3.o?

[Jeff Bevis]

If the math functions are part of libgcc, then can we use this source to 
build libraries that are used for our product?  I am sure that my employer 
would not allow me to release source code to the public.  Thus, I am 
concerned about the GPL.  The library sources are covered by that, and if 
we build libraries from that source and it goes into our product, aren't we 
violating the conditions of the GPL?

At 11:33 PM 6/24/00 -0700, Doug Evans wrote:
>Jeff Bevis writes:
>  > We are having the same kinds of problems here with the powerpc cross
>  > compiler.  Math functions are poorly (if at all) documented, I am afraid.
>  > If someone can point to a good reference, I would be very 
> grateful.  We're about
>  > to embark on the construction of a FP math emulation library, and I 
> honestly
>  > have no idea where to start on that yet.  It does not appear to be 
> part of newlib :^(
>
>It's not supposed to be part of newlib.
>It's part of libgcc.  See, for example, gcc/config/fp-bit.c.
>I see fp-bit.c mentioned in several t-* files in gcc/config/rs6000.


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

Re: Where are _modsi3.c and/or _modsi3.o?

[Doug Evans]

Jeff Bevis writes:
 > If the math functions are part of libgcc, then can we use this source to 
 > build libraries that are used for our product?  I am sure that my employer 
 > would not allow me to release source code to the public.  Thus, I am 
 > concerned about the GPL.  The library sources are covered by that, and if 
 > we build libraries from that source and it goes into our product, aren't we 
 > violating the conditions of the GPL?

Good question.  While libgcc is _not_ GPL'd (it's GPL + exception),
the exception doesn't grant unlimited use.  Alas, IANAL so I'm not
sure you can use it or not.  You _can_ use it if all you're doing is
linking the file into your program.  But if wish to take the sources and
hack on them to create your own fp emulation library or add it to
your own library, you may be (probably are) out of luck.

Here's the exception, btw:
In addition to the permissions in the GNU General Public License, the
Free Software Foundation gives you unlimited permission to link the
compiled version of this file into combinations with other programs,
and to distribute those combinations without any restriction coming
from the use of this file.  (The General Public License restrictions
do apply in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine
executable.)

[btw, I'm assuming you're refering to the functions that fp-bit.c
provides, rather than libm.  You did say "FP math emulation library".]

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

Re: Where are _modsi3.c and/or _modsi3.o?

[Jeff Bevis]

At 06:16 PM 6/24/00 -0500, Christopher Bahns wrote:
>Bonus question:
>Is there a GCC option to generate an assembly listing without affecting
>the build process. I know about the '-S' option, which generates
>assembly code INSTEAD of object code (unless I'm just not using it
>right).

Actually, Christopher, there's more to it than just the -alh option on the 
assembler.  Here's the text from the assembler's manual:

--------------------------------------
Enable Listings: -a[cdhlns]

These options enable listing output from the assembler. By itself, `-a' 
requests high-level, assembly, and symbols listing. You can use other 
letters to select specific options for the list: `-ah' requests a 
high-level language listing, `-al' requests an output-program assembly 
listing, and `-as' requests a symbol table listing. High-level listings 
require that a compiler debugging option like `-g' be used, and that 
assembly listings (`-al') be requested also.

Use the `-ac' option to omit false conditionals from a listing. Any lines 
which are not assembled because of a false .if (or .ifdef, or any other
conditional), or a true .if followed by an .else, will be omitted from the 
listing.

Use the `-ad' option to omit debugging directives from the listing.

Once you have specified one of these options, you can further control 
listing output and its appearance using the directives .list, .nolist, .psize,
.eject, .title, and .sbttl. The `-an' option turns off all forms 
processing. If you do not request listing output with one of the `-a' 
options, the
listing-control directives have no effect.

The letters after `-a' may be combined into one option, e.g., `-aln'.



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

Where are _modsi3.c and/or _modsi3.o?

[Doug Evans]

Christopher Bahns writes:
 > I built binutils/gcc/newlib on my machine (Windows 98/NT, for m68k-coff
 > target), and things are basically going ok, but I'm having trouble with
 > the mod ('%') operator. I looked at the assembly language output and see
 > that it has a 'jsr __modsi3'. I check the map file and find the
 > '__modsi3' routine as follows:
 > 
 >  .text          0x00008c9c       x2e
 > /gcc-m68k/lib/gcc-lib/m68k-coff/2.95.2/libgcc.a(_modsi3.o)
 >                 0x00008c9c                __modsi3
 > 
 > I extracted the source but could not find a file that fit the '_mod*' or
 > '_mod*.*' patterns, using both the Cygwin/Unix 'find' command and
 > Microsoft Explorer's find program. I re-built the compiler and also
 > could find no such object file in the build directory. I'd like to look
 > at the source code to find out if the arguments are being passed
 > properly.

grep for modsi in gcc/config/m68k/*
Maybe the one in libsf68.asm is the one you're looking for,
but it says it's only for m68k's w/o an fpu.

 > Bonus question:
 > Is there a GCC option to generate an assembly listing without affecting
 > the build process.

-save-temps
It'll give you the .s file (and the .i file).  It's not a "listing"
if you wish to define that as including C though.
The files go in the same directory as the .o.

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

RE: Where are _modsi3.c and/or _modsi3.o?

[Scott Howard]

One easy way is to use m68k-coff-gcc to link rather than invoking
m68k-coff-ld directly, and pass it the -m68000 option on the command line.
gcc will then invoke the linker and add the correct directory to the
linker's list of library search paths.

Scott

-----Original Message-----
From: crossgcc-owner@sourceware.cygnus.com
[ mailto:crossgcc-owner@sourceware.cygnus.com]On Behalf Of Christopher
Bahns
Sent: Monday, June 26, 2000 12:05 PM
To: crossgcc@sourceware.cygnus.com
Subject: [Fwd: Where are _modsi3.c and/or _modsi3.o?]


Thanks for the info. After much analysis I finally figured out my problem,
but
could still use a bit more help. My m68k cross compiler was linking with the
wrong
library. It appears that when I build the cross compiler, it makes several
versions
of libgcc.a:

/gcc-m68k/lib/gcc-lib/m68k-coff/2.95.2/
/gcc-m68k/lib/gcc-lib/m68k-coff/2.95.2/m68000/
/gcc-m68k/lib/gcc-lib/m68k-coff/2.95.2/m5200/
/gcc-m68k/lib/gcc-lib/m68k-coff/2.95.2/mcpu32/

By default it links with the first one, in the m68k-coff "root" directory I
suppose. If I delete this file and do one of the following, the mod operator
works:

1. Make a symbolic link for libgcc.a in ".../2.95.2/" to
".../2.95.2/m68000/libgcc.a".
- or -
2. Add the library path ".../2.95.2/m68000" in my makefile (with the -L
option) or
with a SEARCH_DIR() command in the linker command script.

My question now is:
How can I link to the libgcc.a in the m68000 subdirectory without deleting
the one
in the parent directory?

I tried #2 above without deleting the default libgcc.a and that did not
work. I'd
prefer not to mess with the files that are installed for the compiler if I
can help
it. The way I'm doing it I'll have to remember each time I rebuild or
reinstall the
compiler to make this little change before I can actually build something.
I'm
trying to get this stuff together for other people to install and use on
their own
machines, so it would be nice to avoid these complications and minimize the
chance
for error. If I can do everything in the makefile and linker script that
would be
nice.

Thanks a for any help
Chris

Jeff Bevis wrote:

> Hi Christopher,
>
> I am glad to help if I can.  Porting our software from a Diab-compiled
> environment into one which is gcc-compiled has given me a new level of
> appreciation for help in whatever form it arrives.  :^)
>
> The situation I am facing is more of a problem with the GPL than actual
> coding, but it is both.  I can't release the source code to our product
> publicly;  it's not an option.  We have a custom OS, which requires us to
> build our own libraries (it's all done with shared modules, kind of like
> DLLs) for things like FP math (sadly, we have no FPU in our system).   The
> gnu compiler generates lots of references to 64-bit math functions and so
> forth, and I guess I just haven't found the definitive reference on this
> yet.  I don't know the complete set of functions. That was part 1; part 2
> of the problem is that using the gnu library source to build our libraries
> (the FP math again) appears to violate the GPL, as we would not be able to
> release source.  Looking for FP math in newlib, I have found nothing.  So
> does this mean we have to write FP math from scratch?  EEEeeeek!
>
> So we're not really experiencing bugs, per se, as much as we're having
> trouble understanding what functions are required, what their prototypes
> are, and so forth.  And then of course that issue of legality with GPL.
>
> At 08:24 PM 6/24/00 -0500, you wrote:
> >About the assembly listing options, I don't think I want to do it exactly
> >the way
> >you say because if I invoke the assembler directly it does not use all of
the
> >default paths. Invoking the assembler/linker through 'gcc' causes it to
> >include
> >all of the necessary paths. Why it works this way I'm not sure. Russ Shaw
> >recommended calling gcc with '-Wa,-aldh', which is probably what I want
to do.
> >Anyway, I'll try it and see.
>
> Yeah, that sounds right.  I prefer doing it separately in our setup, but
> you can pass options on to the assembler via the compiler, too.  I'm not
> sure of the options, but that looks right.  Beware the huge amount of
debug
> that goes into your .o files now, you'll have to have the linker remove
> that in the output file unless you can tolerate a HUGE file.  :^)


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