dblaikie added a comment.
In D146595#4218040 <https://reviews.llvm.org/D146595#4218040>, @augusto2112
wrote:
>>>> What would happen if, instead, these trampolining functions were annotated
>>>> nodebug? I guess then you wouldn't have the top level one as an entry
>>>> point for the user, as there would be no debug info for it?
>>>
>>> These trampoline functions can call other functions as part of their setup,
>>> so annotating them with nodebug wouldn't guarantee that the debugger would
>>> be able to step through to the correct place. Additionally, you wouldn't be
>>> able to refer to them in LLDB expression evaluation either.
>>
>> Oh, that's a bit worrying - that these aren't trampolines in the sort of
>> lower-level sense, only in a high level sense.
>>
>> Is the ability to debug these functions under some debugger flag ("show me
>> intermediate steps/implementation details") a priority? Would it be OK if
>> that were only available with a rebuild (ie: maybe didn't need to be
>> represented in DWARF - this would also allow debug info to be smaller & not
>> having to describe these transparent/implementation detail functions)?
>
> You mean step in the trampoline? It'd be nice, but not absolutely required.
> The main issue would be not being able to evaluate expressions though.
Right - yep yep.
>> Is there a single public entry point in most cases? How bad would it be if
>> the implementation functions were all nodebug, but the public entry point
>> and underlying function had debug info? Would that provide most/enough of
>> the benefits you're after?
>
> Let me make sure I understand your suggestion, you mean we'd have three
> functions?
>
> void target() {
> // do stuff
> }
>
> // attribute (nodebug)
> void trampoline() {
> // do setup
> target()
> // do cleanup
> }
>
> void entrypoint() {
> trampoline()
> }
>
> Wouldn't users still have to step into the compiler generated `entrypoint`,
> and step in more to get to `target`?
Yep - wondering just how bad that'd be - how much abstraction you're trying to
get past, etc.
> Also, depending the complexity of the trampoline algorithm, a step in still
> isn't guaranteed to stop in the `target` function: I think, as it's
> implemented right now, LLDB stepping into a function with no debug info will
> try to follow the first function call, and step out if that isn't somewhere
> with no debug info. We //could// change the step in algorithm, but a function
> with no debug info isn't necessarily a trampoline, and could have a chain of
> calls to other functions without debug info as well, and having the debugger
> stop at every one of those calls could be pretty expensive. This solution
> would be more performant, as we could set a private breakpoint in the
> `target` and continue the program.
True - being unable to tell whether there's something interesting in there or
not does complicate things.
I'm coming around to maybe this is the best tradeoff, though not /super/
enthusiastic - if there was some way to annotate in a way that's easier for
users (like a bit on the function - "transparent" or something - that lets you
call the function, but is sort of nodebug-ish (skip any calls that don't have
debug info, step further into other functions that have this transparent
attribute on them until you reach something with debug info)) - because there's
probably a lot of functions in things like the standard library that'd be nice
to skip over - or have the debugger skip over them in the same way (currently I
think lldb hardcodes skipping over things in the std namespace, but fails to
step into user code inside those calls - like `make_unique` - you can't step
into the user's ctor, it skips over th ewhole thing - admittedly there you'd
still need the whole implementation call chain to be annotated with transparent
so the debugger knew which bits to step into V over)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D146595/new/
https://reviews.llvm.org/D146595
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
