[PATCH] D48807: Add llvm::Any

[Zachary Turner via Phabricator via llvm-commits]

zturner added a comment.

In https://reviews.llvm.org/D48807#1156823, @dblaikie wrote:

> In https://reviews.llvm.org/D48807#1150245, @zturner wrote:
>
> >   This can arise on Windows (wow64) as well as MachO (universal binaries).  Maybe other platforms as well.  You could probably narrow it to a variant, but we don’t have variant in llvm either and it’s much harder to implement and im not sure it buys much.
>
>
> I'd say variant buys a fair bit in terms of type safety/self-documenting code. I worry about both variant and any in terms of what they do to type safety/contracts between different pieces of code, hence my pushback on adding these kinds of constructs to LLVM.
>
> > Also, in a system where events are passed around and potentially held onto by user code for a long time, it’s useful to have a generic “Tag” field that the user can attach arbitrary data to. This is another potential use case which I didn’t mention before.
>
> I'm still having a little trouble understanding what code is going to consume these events (& how's it going to know/support the different kinds of things in them) given how arbitrary (no common interface, etc) they may be?


There are certain things that are common to all platforms, and certain things that aren't.  For example, if your process hits a trap instruction like an `int 3`, then no matter what platform you're on, there's going to be an address at which it occurred, a process id and thread id in the tracee, and a register context.  On Windows, you'll have an `EXCEPTION_DEBUG_INFO` structure (https://msdn.microsoft.com/en-us/library/windows/desktop/ms679326(v=vs.85).aspx) which contains various other OS-specific bits of information that could be useful to platform specific code.  I'm not sure what other things you might have on Linux, OSX, or BSD, but it's safe to assume there's something.  If not specifically for a trap, for some kind of event (For example, when you call `ptrace` and it returns, it might have returned for many different reasons, and each reason means different info is available to query).

So the point of all this is: When a platform-specific event occurs, there is platform specific data associated with that event, only some of which can be factored out into a common interface, but all of which can be useful in certain scenarios.

So we give back the user an event object that has as wide of a common interface as possible, but still doesn't prevent access to all of the bits.  The consumer of the common interface will be common code.  Code that wants to decide what to do after hitting a breakpoint probably doesn't need all this platform specific information.  It can just stop, look up line and symbol information based on the address, and report it to the user.  But in a system like this which has deep hooks into the OS, it will be very frequent that the code handling an event needs to do something completely different depending on the platform.  So we branch out into platform specific code, and in that platform specific code we know how to consume the platform specific event data.


https://reviews.llvm.org/D48807