Re: GDB shared library tracking with stap probes x _dl_debug_state

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

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.