llvm dev - Apr 2015 - [LLVMdev] About the "debugger target"

While I've already posted reviews for the initial patches for this (see
http://reviews.llvm.org/D8506 and http://reviews.llvm.org/D8599), the
grapevine suggests I should post a lengthier description of my intent
for the "debugger target." The idea was prompted by a suggestion from 
Eric Christopher, and I'm running with it.

Various bits of the DWARF we produce are conditional on the target
platform, or on command-line options with defaults based on the target
platform.  Other bits aren't but probably ought to be.  Some of these 
are little things:
- various Apple-defined attributes (DW_AT_APPLE_*)
- TLS opcode (DW_OP_form_tls_address v. DW_OP_GNU_push_tls_address)

Some are bigger things:
- accelerator tables
- pubnames/pubtypes

Really these aren't so much _platform_ specific things as they are
_debugger_ specific things. For example:
- accelerator tables: default on for Darwin, but really on for LLDB.
- pubnames/pubtypes: off for Darwin and PS4, but really on for GDB.

We're co-opting platform as a proxy for the debugger.  Sometimes they
are closely tied, but in other cases maybe not so much.  I think it is
already the case that LLDB is used in more places than just Darwin?
But the things that look like they ought to be LLDB-specific are actually
implemented as Darwin-specific.  That's sub-optimal for the non-Darwin 
but LLDB-using platforms.  I mean, LLDB will still *work* on those 
platforms, because 99% of what's going on is still standard DWARF, it 
just won't be "tuned" for how LLDB wants to operate.

In most cases on the LLVM side, control of one of these tuning things
is via a bool flag in DwarfDebug, and the DwarfDebug ctor is where the
actual decision-making takes place.  My initial patch to define a 
debugger target starts in the direction of setting those flags based on
debugger, not platform.  More could be done, but as I'm not clear on 
LLDB's scope I didn't want to go too far right away.

For example, it would not make me sad to suppress the DW_AT_APPLE* stuff 
except when the debugger would actually understand it.  It's not clear
to me whether these really ought to be LLDB attributes, or Darwin, or
what, because currently we emit them unconditionally. :-P

And quite frankly, I'm looking ahead to fiddling things for PS4. We have 
no use for linkage names in DWARF, for example, so I'd like to turn that 
off and save some space.  We do want .debug_aranges so I'd like to turn 
that on by default.  And there's a little bit of fine-tuning on exactly
what -flimit-debug-info applies to, that we'd like to do (that part is
obviously on the Clang side rather than the LLVM side).

I hope this helps explain what's going on with the "debugger
target"
and what I want to do with it. (And apologies for not posting this
sooner.)
--paulr

Adding lldb-dev.

LLDB is used in many places other than Darwin; it's used for Linux, Android,
FreeBSD, Hexagon, Kalimba and many others.

The problem with having the compiler build for a specific debugger is you
don't necessarily know at compile which debugger someone will use.
There's
nothing that says you can't build an executable with clang and then debug it
with both gdb and lldb. I've done that.

Ted

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Robinson, Paul
Sent: Wednesday, April 15, 2015 5:32 PM
To: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers
Mailing List (llvmdev at cs.uiuc.edu)
Subject: [LLVMdev] About the "debugger target"

While I've already posted reviews for the initial patches for this (see
http://reviews.llvm.org/D8506 and http://reviews.llvm.org/D8599), the
grapevine suggests I should post a lengthier description of my intent for
the "debugger target." The idea was prompted by a suggestion from Eric
Christopher, and I'm running with it.

Various bits of the DWARF we produce are conditional on the target platform,
or on command-line options with defaults based on the target platform.
Other bits aren't but probably ought to be.  Some of these are little
things:
- various Apple-defined attributes (DW_AT_APPLE_*)
- TLS opcode (DW_OP_form_tls_address v. DW_OP_GNU_push_tls_address)

Some are bigger things:
- accelerator tables
- pubnames/pubtypes

Really these aren't so much _platform_ specific things as they are
_debugger_ specific things. For example:
- accelerator tables: default on for Darwin, but really on for LLDB.
- pubnames/pubtypes: off for Darwin and PS4, but really on for GDB.

We're co-opting platform as a proxy for the debugger.  Sometimes they are
closely tied, but in other cases maybe not so much.  I think it is already
the case that LLDB is used in more places than just Darwin?
But the things that look like they ought to be LLDB-specific are actually
implemented as Darwin-specific.  That's sub-optimal for the non-Darwin but
LLDB-using platforms.  I mean, LLDB will still *work* on those platforms,
because 99% of what's going on is still standard DWARF, it just won't be
"tuned" for how LLDB wants to operate.

In most cases on the LLVM side, control of one of these tuning things is via
a bool flag in DwarfDebug, and the DwarfDebug ctor is where the actual
decision-making takes place.  My initial patch to define a debugger target
starts in the direction of setting those flags based on debugger, not
platform.  More could be done, but as I'm not clear on LLDB's scope I
didn't
want to go too far right away.

For example, it would not make me sad to suppress the DW_AT_APPLE* stuff
except when the debugger would actually understand it.  It's not clear to me
whether these really ought to be LLDB attributes, or Darwin, or what,
because currently we emit them unconditionally. :-P

And quite frankly, I'm looking ahead to fiddling things for PS4. We have no
use for linkage names in DWARF, for example, so I'd like to turn that off
and save some space.  We do want .debug_aranges so I'd like to turn that on
by default.  And there's a little bit of fine-tuning on exactly what
-flimit-debug-info applies to, that we'd like to do (that part is obviously
on the Clang side rather than the LLVM side).

I hope this helps explain what's going on with the "debugger
target"
and what I want to do with it. (And apologies for not posting this
sooner.)
--paulr


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> From: Ted Woodward [mailto:ted.woodward at codeaurora.org]
> 
> Adding lldb-dev.
> 
> LLDB is used in many places other than Darwin; it's used for Linux,
> Android,
> FreeBSD, Hexagon, Kalimba and many others.
> 
> The problem with having the compiler build for a specific debugger is you
> don't necessarily know at compile which debugger someone will use.
There's
> nothing that says you can't build an executable with clang and then
debug
> it
> with both gdb and lldb. I've done that.
Of course LLDB is fully capable of debugging a GDB-tuned executable; that's 
exactly what it does today, on non-Darwin platforms.  This proposal doesn't
really introduce anything new, functionally; it's mostly a way of thinking
about what we're already doing, and providing more control to the user.

And, with exactly one exception, GDB ought to be fully capable of debugging
an LLDB-tuned executable; I'm not aware of any environment where it happens
today *by default* but I don't see anything in the compiler that suggests
there would be any problem.

The exactly-one-exception is: GDB has never been taught how to use the
standard DWARF TLS opcode.  This is a bug in GDB.
https://sourceware.org/bugzilla/show_bug.cgi?id=11616
If you have thread-local variables and ever expect to use GDB to debug,
you should tune for GDB.  Of course that's exactly what you get by default
(with or without my patch) on every non-Darwin non-PS4 platform.

This is *fine-tuning* not an extensive customization.  Actually mostly what 
I have in mind is leaving out peripheral lumps of DWARF that only one or 
another debugger know how to take advantage of; having any of those lumps 
exist when you're using a different debugger causes no harm (except making 
your object files bigger) and have a lump be missing when a debugger could 
use it causes little harm (typically might make the debugger operate a little 
slower because some optimized table isn't available).

--paulr
> 
> Ted
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> 
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] On
> Behalf Of Robinson, Paul
> Sent: Wednesday, April 15, 2015 5:32 PM
> To: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM
Developers
> Mailing List (llvmdev at cs.uiuc.edu)
> Subject: [LLVMdev] About the "debugger target"
> 
> While I've already posted reviews for the initial patches for this (see
> http://reviews.llvm.org/D8506 and http://reviews.llvm.org/D8599), the
> grapevine suggests I should post a lengthier description of my intent for
> the "debugger target." The idea was prompted by a suggestion from
Eric
> Christopher, and I'm running with it.
> 
> Various bits of the DWARF we produce are conditional on the target
> platform,
> or on command-line options with defaults based on the target platform.
> Other bits aren't but probably ought to be.  Some of these are little
> things:
> - various Apple-defined attributes (DW_AT_APPLE_*)
> - TLS opcode (DW_OP_form_tls_address v. DW_OP_GNU_push_tls_address)
> 
> Some are bigger things:
> - accelerator tables
> - pubnames/pubtypes
> 
> Really these aren't so much _platform_ specific things as they are
> _debugger_ specific things. For example:
> - accelerator tables: default on for Darwin, but really on for LLDB.
> - pubnames/pubtypes: off for Darwin and PS4, but really on for GDB.
> 
> We're co-opting platform as a proxy for the debugger.  Sometimes they
are
> closely tied, but in other cases maybe not so much.  I think it is already
> the case that LLDB is used in more places than just Darwin?
> But the things that look like they ought to be LLDB-specific are actually
> implemented as Darwin-specific.  That's sub-optimal for the non-Darwin
but
> LLDB-using platforms.  I mean, LLDB will still *work* on those platforms,
> because 99% of what's going on is still standard DWARF, it just
won't be
> "tuned" for how LLDB wants to operate.
> 
> In most cases on the LLVM side, control of one of these tuning things is
> via
> a bool flag in DwarfDebug, and the DwarfDebug ctor is where the actual
> decision-making takes place.  My initial patch to define a debugger target
> starts in the direction of setting those flags based on debugger, not
> platform.  More could be done, but as I'm not clear on LLDB's scope
I
> didn't
> want to go too far right away.
> 
> For example, it would not make me sad to suppress the DW_AT_APPLE* stuff
> except when the debugger would actually understand it.  It's not clear
to
> me
> whether these really ought to be LLDB attributes, or Darwin, or what,
> because currently we emit them unconditionally. :-P
> 
> And quite frankly, I'm looking ahead to fiddling things for PS4. We
have
> no
> use for linkage names in DWARF, for example, so I'd like to turn that
off
> and save some space.  We do want .debug_aranges so I'd like to turn
that
> on
> by default.  And there's a little bit of fine-tuning on exactly what
> -flimit-debug-info applies to, that we'd like to do (that part is
> obviously
> on the Clang side rather than the LLVM side).
> 
> I hope this helps explain what's going on with the "debugger
target"
> and what I want to do with it. (And apologies for not posting this
> sooner.)
> --paulr
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev