binutils 2.9.1 gas problem (growing frags)

binutils 2.9.1 gas problem (growing frags)

[Vaughan Hillman]

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

Re: binutils 2.9.1 gas problem (growing frags)

[Ian Lance Taylor]

   Date: Thu, 10 Jun 1999 11:40:19 -0700 (PDT)
   From: Vaughan Hillman <hillman_97@yahoo.com>

   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.

I think this problem has been fixed since the 2.9.1 release.  Look at
the current version of frag_grow in frags.c.

If you can't get CVS to work for you, use the cvsweb interface.  For
example, the current frags.c can be seen at
    http://sourceware.cygnus.com/cgi-bin/cvsweb.cgi/binutils/gas/frags.c?rev=1.1.1.1 &content-type=text/x-cvsweb-markup&cvsroot=binutils

Ian