[LLVMdev] What does "debugger tuning" mean?

Daniel Berlin dberlin at dberlin.org
Fri May 1 15:14:51 PDT 2015


On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul
<Paul_Robinson at playstation.sony.com> wrote:

>
> LLVM already emits DWARF slightly differently for different *targets*;
> primarily Darwin, in a few cases PS4.  But in at least some cases, the
> target is just a (somewhat unreliable) proxy for which *debugger* the
> compiler expects to be consuming the DWARF.  The most instructive case
> is the exact DWARF expression used to describe the location of a thread-
> local variable.  DWARF v3 defined an operator to find the base address
> of the thread-local storage area; however, GDB has never learned to
> recognize it.  Therefore, for targets where we "know" GDB isn't used,
> we can emit the standard operator; for targets where GDB *might* be
> used, we need to emit the equivalent (non-standard) GNU operator.
>
> It would be semantically more meaningful to base decisions like this on
> whether we expected the debugger to be X or Y or Z.

How is this not actually "we expect the debugger to want his described
as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".

Debuggers change over time.

GDB 4's level of support != GDB 5 != GDB6 != GDB7.

Heck, the same version of GDB on different platforms can be very
different (HP's GDB was very different, as was Apple's).

Do you plan on having "debugger tuning" flags for each of these?

I am having a lot of trouble understanding how this is about what
debuggers expect and not "ways of representing things".

Otherwise, i see you getting stuck introducing tons and tons of
debugger tunings, instead of people who want it to work a certain way
building an option profile consisting of
"--debugging-feature=use-tls-operator
--debugging-feature=explicit-anonymous-namespace", and getting exactly
what they want.

IE a year from now, somebody comes along with a version of GDB that
doesn't match what your current "tuning profile" is, and asks for it
to change.



More information about the llvm-dev mailing list