Re: GDB shared library tracking with stap probes x _dl_debug_state
Luis Machado via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel,gmane.linux.systemtap,gmane.comp.lib.glibc.alpha |
|---|---|
| Message-ID | <[email protected]> |
Maciej, Do you have any feedback on this for MIPS? On 5/10/21 11:16 AM, Luis Machado wrote: > cc-ing Maciej and Ulrich for feedback about MIPS / rs6000. I see both > architectures rely on marking some symbols as special, for different > purposes. > > On 5/8/21 7:55 AM, Florian Weimer wrote: >> * Sergio Durigan Junior: >> >>> On Friday, May 07 2021, Luis Machado via Gdb wrote: >>> >>>> On 5/7/21 5:44 PM, Florian Weimer wrote: >>>>> * Luis Machado via Libc-alpha: >>>>> >>>>>> That's all fine, but there is one small detail that doesn't work for >>>>>> armhf, and that is discovering if we're dealing with a PC that is arm >>>>>> mode or thumb mode. >>>>> Is it possible to recognize Arm mode vs thumb mode based on the NOP >>>>> encoding at the probe address? >>>>> >>>> >>>> If we know the instruction is a NOP, it might be possible. >>> >>> I think it's guaranteed that the instruction is always going to be a >>> NOP. > > That's good, but ... > >> >> Maybe we can add a comment to that effect to the Systemtap sources? >> >> Start of the thread is here: >> >> <https://sourceware.org/pipermail/gdb/2021-May/049421.html> >> >> I think there are four distinct two-byte patterns at the probe >> addressing, depending on endianess and thumb/non-thumb mode. Looking at >> the instruction has the clear advantage that it works with today's >> binaries. > ... the way the breakpoint selection works doesn't take into account > additional input like this. It would be a non-trivial change. Not too > complex, but still not trivial. > > If this is to be implemented, it would be nice to make sure there are > other architectures affected by this problem and that this sort of > solution also works for them. > > Maciej, do you think MIPS will run into the same issue? If so, is this > an acceptable solution? > > I still think having the symbol information is a cleaner solution.