On Thu, Nov 08, 2012 at 04:27:54PM +0100, Sedat Dilek wrote: > On Thu, Nov 8, 2012 at 4:08 PM, Edgar E. Iglesias > <[email protected]> wrote: > > On Thu, Nov 08, 2012 at 03:53:26PM +0100, Sedat Dilek wrote: > >> On Fri, Nov 2, 2012 at 11:58 PM, Petr Machata <[email protected]> wrote: > >> > "Edgar E. Iglesias" <[email protected]> writes: > >> > > >> >> On Fri, Nov 02, 2012 at 06:07:50PM +0100, Sedat Dilek wrote: > >> >>> This happens with latest ltrace-git... > >> >>> > >> >>> ./ltrace: proc.c: 755: breakpoint_for_symbol: Assertion `bp->libsym == > >> >>> ((void *)0)' failed. > >> >>> > >> >> I've seen this bug, and I'm actually inclined to think that the assert > >> >> should go away and that we instead should somehow just not use that > >> >> break point. But not sure, maybe Petr has more input on this. > >> > > >> > If you assign more than one symbol to a breakpoint, and that breakpoint > >> > hits, there's no way to tell which of the symbols actually hit. So > >> > there's no point storing more than one symbol to a breakpoint. We could > >> > still drop the assert and just ignore the symbol, as you write. > >> > > >> > What might make sense is having several breakpoint handlers per > >> > breakpoint, so that ltrace allows several service breakpoints per > >> > address. Software singlestepping in particular should work well even if > >> > it steps over another breakpoint, service or not. (As should normal > >> > singlestepping, and I'm not positive that it does, but that's a > >> > different can of worms.) > >> > > >> >> The issue I've seen is with weak symbols that are made to point to > >> >> other symbols. I think, I saw it with strlen IIRC. In our glibc, > >> >> strlen points resolves to the same addr as __strlen but it's got > >> >> it's own PLT entry and symbol. > >> > > >> > Hmm, how about having two PLT slots, each for a different symbol, but > >> > those symbols are aliases in the target library. Ltrace filters > >> > aliases, but only for purposes of -x. For -e there's no way to tell > >> > that they end up being aliases. And normally you don't care anyway, but > >> > on MIPS breakpoints are put not to PLT slots, but to destination > >> > addresses. That's how you end up needing two breakpoints on the same > >> > address. Could it be the cause? > >> > > >> > If yes, then the reproducer is as simple as -e func -x func. > >> > > >> >> I've got a local patch for it, but I unfortunately I haven't had much > >> >> time lately to look at it further. My plan was to create a test case > >> >> that hopefully can trig the issue on x86 aswell. Then we can work out > >> >> a solution from there. > >> > > >> > I guess on x86, one could trigger the same by IFUNC symbols, but those > >> > will need to be supported at all in the first place. > >> > > >> > >> Hi Edgar, > >> > >> Any news or even patch(es) around for this issue? > >> > >> I re-tested with ltrace-0.7.0-git1584cfc again to see if any new > >> changes did or did not break build on MIPSEL (own toolchain built with > >> Freetz build-system). > >> Building is fine, but the reported issue still remains. > >> > >> I can only help with more testing these days... > > > > > > Hi Sedak, > > > > This was the latest patch in my tree when I had to stop. I need to go > > through this before something can be submitted. But if you want to try it > > out, that would help. > > > > Test results attached.
Thanks. Looks like it passed ok no? Cheers _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
