Re: GDB shared library tracking with stap probes x _dl_debug_state

[Luis Machado <luis.machado@linaro.org>]

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.