Re: [RFA] "continue" after "attach" fails on sparc64-solaris

[Joel Brobecker <brobecker at adacore dot com>]

This one is relatively straightforward, I think. I could commit it
in a week or so unless there are objections, but I am afraid that
it might be priviledge abuse (and I welcome feedback). Since it's
been out for review for a while, I'll wait another week before
checking it in. But do let me know if I'm abusing my priviledges.

> I finally got a chance to look into something that Daniel hinted at
> a while ago, when I modified solib-svr4.c to use the AT_BASE entry of
> the auxiliary vector in order to find the base load address.
> 
> The problem was the following:
> 
>     (gdb) attach ...
>     (gdb) c
>     Continuing.
>     Warning:
>     Cannot insert breakpoint -1.
>     Error accessing memory address 0xff36159c: I/O error.
> 
> I fixed the problem by implementing a suggestion to use the AT_BASE
> attributed, but as it turns out, this was only good enough for sparc32.
> As far as I can tell, the auxilliary data obtained when running a 64bit
> app looks screwed. So we still have the same problem on sparc64.
> Surprisingly, it seems to affect only multi-threaded programs.
> 
> Daniel said in http://www.sourceware.org/ml/gdb-patches/2007-09/msg00206.html:
> 
> > So, it has attached to the program and decided that it's at the start
> > address.  That means we tried this:
> > 
> >       /* On a running target, we can get the dynamic linker's base
> >          address from the shared library table.  */
> >       solib_add (NULL, 0, &current_target, auto_solib_add);
> >       so = master_so_list ();
> >       while (so)
> > ...
> > 
> > and did not find any loaded libraries or else did not find the
> > interpreter in the list.  That's strange and almost certainly
> > indicates a bug that we should fix.  The loader should have
> > been in the list at that point.  Maybe it has a different
> > filename in the list than in .interp?
> 
> And indeed, the name of the loader changes from /usr/lib/sparcv9/ld.so.1
> (in .interp) to /lib/sparcv9/ld.so.1.
> 
> I took advantage of Volodya's work: Extracted out the work of comparing
> shared library names, extended it to recognize the sparc64 case, and
> then change the string-compare into a call to our specialized comparison
> routine.

2008-02-01  Joel Brobecker  <brobecker@adacore.com>

        * solib-svr4.c (svr4_same_1): New function, originally extracted
        from svr4_same and expanded to handle the sparc64 case.
        (svr4_same): Move up and reimplement using svr4_same_1.
        (enable_break): Use svr4_same_1 to do shared library name comparisons.

Tested on sparc64-solaris2.9. No regression.
OK to apply?

Thanks,
-- 
Joel

Attachment: solib-svr4.c.diff
Description: Text document