This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Help with global partitions
- To: gcc at gcc dot gnu dot org, mgutierrez at oppd dot com
- Subject: Re: Help with global partitions
- From: Mike Stump <mrs at windriver dot com>
- Date: Thu, 4 May 2000 22:58:39 -0700 (PDT)
> From: "GUTIERREZ, MARK L" <mgutierrez@oppd.com>
> To: "'gcc@gcc.gnu.org'" <gcc@gcc.gnu.org>
> Date: Thu, 4 May 2000 13:53:55 -0500
> The following statement is an example of how the shared memory
> segments are defined and logical address assigned in C
> This C routine is used to attach the globals to the correct
> logical location for the FORTRAN models.
> .globl global_snp_
> global_snp_ = 0x8300000
> Using gcc this does not work. It does not assign the logical
> address of global_snp to 8300000. During debugging of this
> problem I created a small FORTRAN pgm and a C definition source
> as follows:
> C routine:-> Filename bshareG.s
> .globl global_snp_
> global_snp_ = 0x8300000
> I compile C routine using:
> gcc -o bshareG.o bshareG.s
First, this isn't a C routine, nor does it have anything to do with C,
or even gcc for that matter. Files that end in a .s as assembly
language files. Sometimes the assembly languages differ from
implementation to implementation and compiler to compiler in subtle
ways. I don't know if it does in this case, but it might. Coding in
assembly, isn't the first choice. This can be coded in C (an
extension to GNU C) as follows:
bash[869] cat t.cc
extern int i __attribute__((alias( "0x8300000")));
int main() {
int j = i;
}
bash[870] gcc -c t.cc
bash[871] nm t.o
00000000 t gcc2_compiled.
08300000 A i
00000000 T main
if you want to code it in C. This does roughly exactly what you seem
to want. Now, we can peek into how the compiler generated assembly
code for that construct (I'm on a Sun SPARC using /bin/as):
kankakee bash[872] gcc -S t.cc
kankakee bash[873] cat t.s
.file "t.cc"
gcc2_compiled.:
.global i
i = 0x8300000
.section ".text"
.align 4
.global main
.type main,#function
.proc 04
main:
.LLFB1:
!#PROLOGUE# 0
save %sp, -120, %sp
.LLCFI0:
!#PROLOGUE# 1
sethi %hi(i), %i0
or %i0, %lo(i), %i0
ld [%i0], %i0
st %i0, [%fp-20]
mov 0, %i0
ret
restore
.LLFE1:
.LLfe1:
Roughly the same syntax as you had. My guess is that this problem
isn't related to the assembly, nor how they link together, but rather
in g77, or a bug in your program. There is a debugger called gdb,
that may be able to help you debug the program. You want to step
through the code, and find out exactly where it stops, and why.
In your case, I suspect your trying to force the address for shmat,
and that address isn't available for allocation (sorry). You don't
error check the return value, this is just wrong. See the manual page
or a book on unix programming for details. You _must_ check the
return status for -1, and if it is, not use it as an address. My
fortran is a little weak, but don't you unconditionally dereference
the pointer?