[ CC Edgar and Oliver ] I remember Edgar and Oliver were helpul on parts of MIPS(EL). IIRC Oliver did also test with Freetz in QEMU/VM.
Maybe they are willing to help, for example how to setup Freetz, etc. BTW, just for the sake of correctness... Can you give Oliver appropriates credits in CREDITS file? Thanks. ( I liked his conversion/consolidation/simplification for MIPSEL. ) - Sedat - [1] http://anonscm.debian.org/cgit/collab-maint/ltrace.git/log/?qt=author&q=Oliver+Spornitz On Mon, Jan 5, 2015 at 5:15 PM, Petr Machata <[email protected]> wrote: > Faraz Shahbazker <[email protected]> writes: > >> On Fri, Jan 2, 2015 at 1:54 PM, Petr Machata <pmachata at redhat.com> wrote: >>> 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. >> >> Just started looking at your branch before the holidays. The >> 'unresolve' logic for pre-linked ELFs is missing > > Yeah, now that I'm looking it, you're right, unprelink isn't written. > The necessary data is stored to libsym->arch.data->got_entry_value and > libsym->arch.data->stub_addr. The former is what's in the GOT entry now > (i.e. the resolved value, the address of the function entry point), the > latter is what should be there (or rather, what ltrace wants there to be > so that tracing works). Calling unresolve_got_entry and > mark_as_resolved in mips_stub_bp_install may be all that's needed. > > You will probably also need to fill in mips_stub_bp_retract, so that > when ltrace detaches, you patch things back up the way they were. At > least on PowerPC this was necessary--prelinking modified the binary such > that the normal dynamic resolution path didn't work, and when a call was > made through an unresolved slot, the process would crash. So you need > to un-unresolve everything again. > >> and some of the calculations need to be biased appropriately. I don't > > Hmm, that's quite possible. This is a perennial source of problems. > Really we should type biased and unbiased addresses differently, but C > is not a good language for these sorts of abstractions. > >> have the necessary domain knowledge, but I do have time, so if someone >> could nudge me in the right direction ... > > I don't really know much about MIPS either. Mostly what helped me > figure this stuff out was staring at objdump -d, eu-readelf and memory > dumps in gdb. Which is to say that I'm not sure how much help I'll be. > But do ask, we should be able to figure this out. > > Thanks, > Petr _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
