This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
binutils 2.9.1 gas problem (growing frags)
- To: "mailinglist:binutils" <binutils@sourceware.cygnus.com>
- Subject: binutils 2.9.1 gas problem (growing frags)
- From: Vaughan Hillman <hillman_97@yahoo.com>
- Date: Thu, 10 Jun 1999 11:40:19 -0700 (PDT)
- Cc: hillman_97@yahoo.com
I am using a cross assembler hosted on
alphaev5-dec-osf4.0b and targeted for powerpc-eabi.
I have attached part of an assembly file that exhibits
the problem.
This is the command that is run which gets the
following output.
powerpc-eabi-as -mppc -V -Qy -o file.o file.s
file.s:184: Fatal error: Can't extend frag 91. chars
It appears that the assembler is reading in the stab
entries from file.s and putting them into an obstack.
Initially it allocates a frag with 4096 bytes to
start off with. When line 184 of file.s is read in
the function frag_grow() is called to see if this line
can be read into the current frag. frag_grow is told
to grow by 91 bytes. The current obstack has 88 bytes
free (chunk_limit-next_free). frag_new() goes and
takes care of the allocation by calling frag_alloc().
Here obstack_alloc() is called. It goes and
allocates a frag for the stack. Since obstack_alloc
is told to allocate SIZEOF_STRUCT_FRAG (which happens
to be 84 bytes) bytes, obstack_blank returns saying
that there was enough space for the 84 bytes (as we
have 88 bytes free) and adds in the new frag header
leaving 4 bytes. We return to frag_grow() having not
allocated a larger frag and the code calls frag_new()
again. This time obstack_blank() allows
_obstack_newchunk() to be called since we are asking
for 84 bytes and have 4 bytes free.
It returns with 168 bytes and the 84 byte header is
taken out again leaving us with 84 bytes. The code in
frag_grow then exits saying that it was unsucessfull
at getting any more memory added to the obstack.
As a temporary fix I have told _obstack_newchunk() to
add on 200 extra bytes instead of the normal 100
bytes.
This leaves me enough memory on the second call to
frag_new(). This obviously isn't the real fix but I
cant seem to find a clean place to put any changes
into. It would almost seem like obstack_alloc()
should get passed a size at least as big as the size
we ask for in frag_grow().
I cant seem to figure out to download the development
binutils sources from the web based interface so I
dont
know if this problem has already been addressed. Is
this a symptom of something else? It appears that
this problem would happen on any system when the same
set of circumstances came together.
I cross assembled this file under Redhat Linux 5.2 and
Solaris 2.6 with binutils 2.9.1 and the problem didn't
exist. I ran gdb on the linux version and the
allocations looked different since the size of
SIZEOF_STRUCT_FRAG is 44 bytes.
Has anyone else seen this behavior?
Any help would be greatly appreciated.
Thanks,
Vaughan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
file.s