This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[RFA] alloca coding standard


On 11-Nov-2000, Andrew Cagney wrote:

>To decide it is appropriate I think there need to be some clear and
>objective guidelines.

How about this?  The appended patch:

  - Documents the de facto coding standard of allowing limited alloca()
    allocations.  I've set the limit at 1 page per function; does anyone
    think it should be less, more, or specified in bytes instead of pages?

  - Briefly describes some of the issues that have been raised.

  - Moves an alloca (0) call from registers_changed() to
    wait_for_inferior(), so that the documentation can say:

      "For systems that use libiberty's alloca emulation, it is important
       that alloca be called when the stack is shallow to garbage-collect
       freed space.  As of this writing, GDB calls alloc (0) once per user
       command and once per inferior wait."

    It seemed more puzzling to say "GDB calls alloca (0) once per register
    cache invalidation", since that happens at less-predictable stack
    depths.

ChangeLog entries:

	* gdbint.texinfo (Alloca): New subsection.
	* infrun.c (wait_for_inferior): Call alloca (0).
	* regcache.c (registers_changed): Move alloca (0) call to
	wait_for_inferior() loop.

Nick

[patch follows]

Index: gdb/doc/gdbint.texinfo
===================================================================
diff -up gdb/doc/gdbint.texinfo gdb/doc/gdbint.texinfo
--- gdb/doc/gdbint.texinfo	Mon Nov 13 01:25:51 2000
+++ gdb/doc/gdbint.texinfo	Mon Nov 13 01:25:15 2000
@@ -2854,6 +2854,24 @@ visible to random source files.
 All static functions must be declared in a block near the top of the
 source file.
 
+@subsection Alloca
+
+@code{alloca} may be used for allocating up to a page of stack memory
+per function call.
+
+The size restriction is a compromise between the benefits of
+@code{alloca} and the risk of stack overflow, which can happen on
+systems that have fixed-length stack regions or bounds on frame sizes.
+
+For systems that use libiberty's @code{alloca} emulation, it is
+important that @code{alloca} be called when the stack is shallow to
+garbage-collect freed space.  As of this writing, @value{GDBN} calls
+@code{alloc (0)} once per user command and once per inferior wait.
+
+Because @value{GDBN} and other GNU programs use @code{alloca}, they are
+not portable to systems that neither provide a native @code{alloca} nor
+support libiberty's emulation of @code{alloca}.
+
 @subsection Clean Design
 
 In addition to getting the syntax right, there's the little question of
Index: gdb/infrun.c
===================================================================
diff -up gdb/infrun.c gdb/infrun.c
--- gdb/infrun.c	Mon Nov 13 01:25:58 2000
+++ gdb/infrun.c	Mon Nov 13 01:23:55 2000
@@ -1282,6 +1282,9 @@ wait_for_inferior (void)
 
   while (1)
     {
+      /* Garbage-collect libiberty's alloca() emulation.  */
+      alloca (0);
+
       if (target_wait_hook)
 	ecs->pid = target_wait_hook (ecs->waiton_pid, ecs->wp);
       else
Index: gdb/regcache.c
===================================================================
diff -up gdb/regcache.c gdb/regcache.c
--- gdb/regcache.c	Mon Nov 13 01:26:00 2000
+++ gdb/regcache.c	Mon Nov 13 01:24:18 2000
@@ -295,13 +295,6 @@ registers_changed (void)
 
   registers_pid = -1;
 
-  /* Force cleanup of any alloca areas if using C alloca instead of
-     a builtin alloca.  This particular call is used to clean up
-     areas allocated by low level target code which may build up
-     during lengthy interactions between gdb and the target before
-     gdb gives control to the user (ie watchpoints).  */
-  alloca (0);
-
   for (i = 0; i < ARCH_NUM_REGS; i++)
     register_valid[i] = 0;
 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]