Mail Archives: djgpp/2001/06/16/03:54:31
> From: "Chris Wilkinson" <chrisw AT wam DOT umd DOT edu>
> Newsgroups: comp.os.msdos.djgpp
> Date: Fri, 15 Jun 2001 16:12:26 -0400
> > >
> > What I'm looking for is to see whether ipmpar.o lists the function
> > ipmpar (symbol name "_ipmpar") with `T'.
>
> Here is the output from nm -A ipmpar.o. No -g switch.
> C:\FFOP\src\OneUnit>nm -A ipmpar.o
> ipmpar.o:000000a0 b .bss
> ipmpar.o:000000a0 d .data
> ipmpar.o:00000000 t .text
> ipmpar.o:00000000 t ___gnu_compiled_c
> ipmpar.o:000000a0 b _imach.3
> ipmpar.o:00000000 T _ipmpar
> ipmpar.o:000000cc b _ipmpar.4
> ipmpar.o:00000000 t gcc2_compiled.
>
> and here with the -g switch
> C:\FFOP\src\OneUnit>nm -A ipmpar.o
> ipmpar.o:00000000 t .bf
> ipmpar.o:000000a0 b .bss
> ipmpar.o:000000a0 d .data
> ipmpar.o:00000094 t .ef
> ipmpar.o:00000000 t .text
> ipmpar.o:00000000 t ___gnu_compiled_c
> ipmpar.o:000000a0 b _imach
> ipmpar.o:000000a0 b _imach.3
> ipmpar.o:00000000 t _ipmpar
> ipmpar.o:000000cc b _ipmpar.4
> ipmpar.o:00000000 t gcc2_compiled.
>
> The difference seems to be that _ipmpar is marked with a 'T' in the first
> case (no -g) and 't' in the second case (-g).
Unbelievable: this is a blatant compiler bug. So blatant that I never
considered the possibility even though it was staring at me since you
posted the source of ipmpar.c.
Andris, could you please see if this problem is fixed in the latest
version of GCC 3.0?
`t' means that the compiler thinks the function ipmpar is declared
static in this module, i.e. it is private: it's meant to be used only
by other functions in that same module, and not visible to other
modules. It's no surprise the linker complains.
The reason for this bug is that ipmpar.c defines 2 symbols by the same
name `ipmpar': one is a function, which has a global scope, i.e. it is
supposed to be known to the other modules; the other is a variable
ipmpar that is declared static, i.e. it is private to this function.
It seems that GCC 2.95.3 becomes confused by this when it needs to
produce the debug info for both these symbols, and somehow mixes the
attributes of them so that `ipmar' becomes a private function!
The good-ole GCC 2.7.2.1 doesn't have this bug. The bug also vanishes
when you use -gstabs+ switch instead of -g, so it is probably specific
to the COFF debug info used by default. Therefore, one solution for
this is to use -gstabs+ instead of -g. It might be a good idea to do
that anyway, since -gstabs+ produces more elaborate debug info and so
allows better debugging.
Another solution is to apply the patch below to ipmpar.c. It renames
the variable to a different name, so GCC doesn't become confused even
with -g.
(I'm guessing that this source was produced by f2c or some similar
tool from a Fortran source, so similar problems might be present in
oher cases where Fortran functions were translated to C, since in
Fortran, a function returns a value by assigning that value to a
variable whose name is the same as the function's. I suggest to go
over your other sources and see whether similar problems are present
in any of them.)
*** ipmpar.c~ Sat Jun 16 10:26:24 2001
--- ipmpar.c Sat Jun 16 10:28:30 2001
***************
*** 68,74 ****
int ipmpar(int *i)
{
static int imach[11];
! static int ipmpar;
/* MACHINE CONSTANTS FOR AMDAHL MACHINES. */
/*
imach[1] = 2;
--- 68,74 ----
int ipmpar(int *i)
{
static int imach[11];
! static int ipmpar_value;
/* MACHINE CONSTANTS FOR AMDAHL MACHINES. */
/*
imach[1] = 2;
***************
*** 421,426 ****
imach[9] = -127;
imach[10] = 127;
*/
! ipmpar = imach[*i];
! return ipmpar;
}
--- 421,426 ----
imach[9] = -127;
imach[10] = 127;
*/
! ipmpar_value = imach[*i];
! return ipmpar_value;
}
- Raw text -