> On Apr 30, 2020, at 12:43 PM, Vangelis Tsiatsianas via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>
> Thank you for the answer, Greg.
>
> I personally managed to work around the problem, although it confused me a
> bit at first and took a while to figure out the cause. May I suggest the
> addition of a note in the documentation of "{Breakpoint,
> Watchpoint}::{Invoke, Set}Callback()" and possibly other relevant functions
> as a warning to future developers that may stumble upon the same issue?
>
> Regarding the public C++ API, would defining "break_id_t" as "int64_t" be a
> viable solution or that change would also break the API? It seems that making
> both types 64-bit alleviates the issue, despite the sign difference.
Mangled names don’t encode typedef names, but the bare type. For instance:
> cat signatures.cpp
#include <stdint.h>
#include <stdio.h>
typedef int64_t break_id_t;
struct Foo {
void GiveMeABreak(break_id_t id) { printf("Got: %d\n", id); }
};
int
main()
{
Foo myFoo;
myFoo.GiveMeABreak(100);
return 0;
}
> clang++ -g -O0 signatures.cpp
> nm a.out | grep GiveMeABreak
0000000100000f50 T __ZN3Foo12GiveMeABreakEx
> c++filt __ZN3Foo12GiveMeABreakEx
Foo::GiveMeABreak(long long)
So this change would change the mangled names of any methods taking a
break_id_t, and mean old clients would get missing symbol errors when running
with the new API’s. So this isn’t something we can do.
Jim
>
>
> ― Vangelis
>
>
>> On 30 Apr 2020, at 22:22, Greg Clayton <clayb...@gmail.com
>> <mailto:clayb...@gmail.com>> wrote:
>>
>>
>>
>>> On Apr 30, 2020, at 8:50 AM, Vangelis Tsiatsianas via lldb-dev
>>> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote:
>>>
>>> Hello,
>>>
>>> I would like to ask a question regarding "BreakpointHitCallback", which is
>>> declared as such:
>>>
>>> bool (*BreakpointHitCallback)(void *baton,
>>> StoppointCallbackContext *context,
>>> lldb::user_id_t break_id,
>>> lldb::user_id_t break_loc_id);
>>>
>>> Is there any particular reason that "break_id" and "break_loc_id" are of
>>> type "user_id_t" (64-bit unsigned) instead of "break_id_t" (32-bit signed),
>>> which is used both for "Stoppoint::m_bid" and "StoppointLocation::m_loc_id"?
>>
>> I believe this callback predated the time when we added break_id and
>> break_loc_id, and since arguments are part of the signature of C++
>> functions, we didn't change it in order to keep the public API from
>> changing. Or this could have just been a mistake. Either way, we have a
>> stable API and can't really change it.
>>>
>>> This causes an issue mainly with internal breakpoints, since the callback
>>> of an internal breakpoint with (ID == 0xfffffffe) is called with (break_id
>>> == 0xfffffffffffffffe), forcing the callback to cast the argument back to a
>>> 32-bit signed in order to use it correctly, e.g. when the IDs are stored
>>> and need to be looked up.
>>>
>>> A small example attempting to illustrate the problem:
>>> https://godbolt.org/z/y8LbK2 <https://godbolt.org/z/y8LbK2>
>> Sorry for the issue, but I think we are stuck with it now.
>>
>>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
