Re: time to workaround libc/13097 in fsf gdb?

[Doug Evans <dje@google.com>]

On Sun, Sep 21, 2014 at 12:46 PM, Pedro Alves <palves@redhat.com> wrote:
>[...]
> @@ -1478,6 +1479,44 @@ svr4_current_sos (void)
>    return svr4_current_sos_direct (info);
>  }
>
> +/* Implement the "current_sos" target_so_ops method.  */
> +
> +static struct so_list *
> +svr4_current_sos (void)
> +{
> +  struct so_list *so_head = svr4_current_sos_1 ();
> +  struct objfile *objfile;
> +  struct obj_section *osect;
> +  CORE_ADDR vsyscall_start, vsyscall_end;
> +
> +  /* Filter out the vDSO module, if present.  Its symbol file would
> +     not be found on disk.  The vDSO/vsyscall's OBJFILE is instead
> +     managed by symfile-mem.c:add_vsyscall_page.  */
> +  if (gdbarch_vsyscall_range (target_gdbarch (),
> +                             &vsyscall_start, &vsyscall_end))
> +    {
> +      struct so_list **sop;
> +
> +      sop = &so_head;
> +      while (*sop != NULL)
> +       {
> +         struct so_list *so = *sop;
> +
> +         if (vsyscall_start <= so->lm_info->l_ld
> +             && so->lm_info->l_ld < vsyscall_end)

This test is subtle enough that I'd appreciate a full explanation here
of what's going on.
Thanks.

> +           {
> +             *sop = so->next;
> +             free_so (so);
> +             break;
> +           }
> +
> +         sop = &so->next;
> +       }
> +    }
> +
> +  return so_head;
> +}
> +

I may have a few more comments, but I think Jan has covered them, so
I'm going to wait until the next version for further review.