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

Doug Evans
2014-09-23T23:05:14Z

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.