This is the mail archive of the gdb-patches@sourceware.cygnus.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]

Re: [RFA] rs6000-nat.c fix for large symtabs.


kevinb wrote:
>> >What's the value of sizeof (*ldi) ?
>> 
>> 26 bytes, I believe.
>
>My test program showed 28 bytes.  (I just wanted a rough idea though.)

Ya got me, I just did a quick count in my head.

>> >I have concerns about growing the stack too large if we fail multiple
>> >times.  I would prefer to see us use xmalloc() and free() in this
>> >situation.  (Putting alloca() in a loop is generally not a good idea.)
>> 
>> I did, too, but given how infrequently this problem is run across
>> I'd be surprised if the loop ever went through more than twice.
>
>I agree with you.
>
>Suppose we make it through the loop three times; Then the total amount
>of stack space consumed for this data structure will be 12544 bytes
>(28 * (64 + 128 + 256)).  If the stack can't accomodate 12K of growth
>by this function, then it's not likely that the gdb process will have
>long to live anyway.

Agreed, but given that people seem to want to move away from alloca()
usage perhaps another fix would be more appropriate.

>Your fix is approved; please check it in.

Approval on this new patch?


Index: rs6000-nat.c
===================================================================
retrieving revision 2.41.60.1
diff -c -r2.41.60.1 rs6000-nat.c
*** rs6000-nat.c	2000/02/14 04:31:53	2.41.60.1
--- rs6000-nat.c	2000/04/10 20:14:33
***************
*** 639,667 ****
  xcoff_relocate_symtab (pid)
       unsigned int pid;
  {
! #define	MAX_LOAD_SEGS 64	/* maximum number of load segments */
  
-   struct ld_info *ldi;
- 
-   ldi = (void *) alloca (MAX_LOAD_SEGS * sizeof (*ldi));
- 
    /* According to my humble theory, AIX has some timing problems and
       when the user stack grows, kernel doesn't update stack info in time
       and ptrace calls step on user stack. That is why we sleep here a little,
       and give kernel to update its internals. */
- 
-   usleep (36000);
- 
-   errno = 0;
-   ptrace (PT_LDINFO, pid, (PTRACE_ARG3_TYPE) ldi,
- 	  MAX_LOAD_SEGS * sizeof (*ldi), (int *) ldi);
-   if (errno)
-     perror_with_name ("ptrace ldinfo");
  
!   vmap_ldinfo (ldi);
  
!   /* relocate the exec and core sections as well. */
!   vmap_exec ();
  }
  
  /* Core file stuff.  */
--- 639,679 ----
  xcoff_relocate_symtab (pid)
       unsigned int pid;
  {
!   int load_segs = 64; /* number of load segments */
!   int rc;
!   struct ld_info *ldi = NULL;
! 
!   do
!     {
!       ldi = (void *) realloc (ldi, load_segs * sizeof (*ldi));
!       if (ldi == NULL)
!         perror_with_name ("xcoff_relocate_symtab");
  
    /* According to my humble theory, AIX has some timing problems and
       when the user stack grows, kernel doesn't update stack info in time
       and ptrace calls step on user stack. That is why we sleep here a little,
       and give kernel to update its internals. */
  
!       usleep (36000);
  
!       errno = 0;
!       rc = ptrace (PT_LDINFO, pid, (PTRACE_ARG3_TYPE) ldi,
!                   load_segs * sizeof (*ldi), (int *) ldi);
!       if (rc == -1)
!         {
!           if (errno == ENOMEM)
!             load_segs *= 2;
!           else
!             perror_with_name ("ptrace ldinfo");
!         }
!       else
! 	{
!           vmap_ldinfo (ldi);
!           vmap_exec (); /* relocate the exec and core sections as well. */
! 	}
!     } while (rc == -1);
!   if (ldi)
!     free (ldi);
  }
  
  /* Core file stuff.  */

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