This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [RFA] rs6000-nat.c fix for large symtabs.
- To: Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: [RFA] rs6000-nat.c fix for large symtabs.
- From: gkm at cygnus dot com (glen mccready)
- Date: Mon, 10 Apr 2000 14:30:38 -0700
- Cc: gdb-patches at sourceware dot cygnus dot com
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. */