On Fri, Jan 2, 2015 at 1:54 PM, Petr Machata <[email protected]> wrote: > Sedat Dilek <[email protected]> writes: > >> On Thu, Jan 16, 2014 at 9:20 PM, Petr Machata <[email protected]> wrote: >>> Eugene Rudoy <[email protected]> writes: >>> >>>> as to compiling the master: I had to apply the two patches attached to this >>>> mail in order to compile it (I simply removed that >>>> "lte->relplt_count"-line). >>> >>> Hmm, the _GNU_SOURCE ones probably make sense (see the comment about >>> uclibc above one of them). > > I pushed the _GNU_SOURCE patch to master now. > >>>> As to fixing the issue, in particular "It shouldn't be hard for MIPS' >>>> arch_elf_init to add any special entries....": sounds interesting ;-) but >>>> it's something completely new to us (Oliver & me), we just cross-compile >>>> ltrace and make it available to the users of freetz-project. >>>> >>>> Would that be possible for you to take a deeper look into the issue? Is >>>> there something we can do to support you? Testing, hardware (probably >>>> remote access only)? >>> >>> In fact I'm installing Debian Wheezy inside Qemu as I write this. >>> I can't promise anything (this would have to go from my personal time >>> budget, which is already fairly strained), but I should be able to at >>> least take a look. >>> >> >> Recently, I was asked some questions about ltrace-0.7.3 MIPS >> cross-compilation. >> >> What happened with this issue? >> Is ltrace-0.7.y still BROKEN on MIPS? >> >> I have seen a "pmachata/mips" Git branch with a patch called "Support >> tracing of PLT-less MIPS binaries" on top... which has not entered >> master. > > So yeah, I spent some time on that (possibly the weekend and then a > couple evenings before 2014-01-21). Looking into my notes, I needed to > move on to Aarch64 support, and the MIPS work must have gradually > slipped my mind. > > It seems like I wanted to redo what PowerPC (and newly Xtensa!) was/is > doing with unresolving PLT slots when they are resolved, so that we > don't have to move breakpoints to function entry points, but can keep > them in PLT. I'm not sure how far I got. The code for this > specifically seems to be in, but it is likely that I broke some other > MIPS use cases, special symbol types or other MIPS magic. > > Someone would need to fix regressions in test cases between > pmachata/mips and 94773bf0b1 (the branch-off point) and fix them. They > would need to have enough domain knowledge to realize where the test > suite has blind spots, what it doesn't test, and add tests and fixes for > these test cases. That someone is unlikely to be me, my personal time > budget is actually even more strained now than it was a year ago. >
Thanks for taking care. Unfortunately, I don't use my Freetz-modded routers anymore (using 3G UMTS/HSPA). Offhand, I cannot tell you how to test MIPS stuff here (I was used to test on bare metal). What are your plans? Do you plan to (cherry-)pick your changes for ltrace-0.7? Can you please add a note about current situation on MIPS, e.g. in the TODO (I haven't checked it)? Have more fun in 2015. - Sedat - P.S.: I will point that guy who asked me about ltrace on MIPS to the ltrace ML-archive. _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
