> -----Original Message----- > From: Daniel Berlin [mailto:dberlin at dberlin.org] > Sent: Friday, May 01, 2015 3:15 PM > To: Robinson, Paul > Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers > Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu > Subject: Re: [LLVMdev] What does "debugger tuning" mean? > > 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".Different ways of describing things let us reason about them in different ways. Are Cartesian coordinates a reason to reject polar coordinates?> Debuggers change over time.Well, they're software too. They're allowed.> 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?Are all of these current supported Clang/LLVM environments? Are they suffering because Clang currently emits DWARF in ways that cause them problems, or that bloats the debug info unnecessarily? Are vendors carrying a pile of private patches to get LLVM to emit DWARF that looks like what their debugger wants? If the answer to these questions is Yes then my answer to your question is Sure, we could, if we find those differences to be important. I promise you that these things are true at Sony, and I would be astounded if it wasn't true for Apple. Guess what? LLDB and SCE are two of the debugger-tuning options for a reason. Show me another _real_ case of _real_ differences that matter to the community, and we can talk about another debugger tuning option.> I am having a lot of trouble understanding how this is about what > debuggers expect and not "ways of representing things".Sometimes there's not much difference in the result, although there is a difference in how we think about it.> 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.(That sort of alternate proposal is way more useful than the straw-man stuff you started out with. Just sayin'.) (Also incidentally, I see gcc 4.8.2 is emitting an explicit import of anonymous namespaces, so that's becoming _less_ different over time.) In fact this is more or less how DwarfDebug operates now; there is a pile (small pile, but still a pile) of individual feature flags that get set various ways depending on target or command-line options. The problem I'm looking at is that the defaults for a lot of these things are based on target, which AFAICT is based on an out-of-date assumption about how target correlates to debugger. I'm proposing to package up known sets of stuff that we're having to contend with _today_ in a way that's easier to talk about and do something about than the target-oriented mish-mash we have now. It's a whole lot simpler to say something like "FreeBSD implies LLDB" instead of "FreeBSD implies accelerator tables and standard TLS opcode and no pubnames or pubtypes." Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref --lang-feature=move_ctor ..." than "-std=c++11"?> 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.If it's meaningfully different, i.e. makes enough of a functional and/or size difference, and it's an environment we collectively want to support, and it's unreasonable to get the necessary effect some other way, then sure, maybe we would want to invent a new tuning profile. But, if it doesn't meet that bar, I don't see why we'd want to. --paulr
On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote:> > -----Original Message----- > > From: Daniel Berlin [mailto:dberlin at dberlin.org] > > Sent: Friday, May 01, 2015 3:15 PM > > To: Robinson, Paul > > Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM > Developers > > Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu > > Subject: Re: [LLVMdev] What does "debugger tuning" mean? > > > > 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". > > Different ways of describing things let us reason about them in different > ways. Are Cartesian coordinates a reason to reject polar coordinates? > > > Debuggers change over time. > > Well, they're software too. They're allowed. > > > 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? > > Are all of these current supported Clang/LLVM environments? Are they > suffering because Clang currently emits DWARF in ways that cause them > problems, or that bloats the debug info unnecessarily? Are vendors > carrying a pile of private patches to get LLVM to emit DWARF that looks > like what their debugger wants? If the answer to these questions is > Yes then my answer to your question is Sure, we could, if we find > those differences to be important. > > I promise you that these things are true at Sony, and I would be > astounded if it wasn't true for Apple.FWIW I'd be surprised if Apple's carrying much internal cost for LLVM's debug info. It was essentially built for ye olde GDB and even when I set about improving it I brought up an external buildbot for that workload to ensure it wasn't broken (& LLDB was built for LLVM's debug info output, so there's not much reason to expect that wouldn't work - the base class declaration's one of the only cases there that I know of - and yes, that's predicated on Darwin & should be predicated on LLDB as you're proposing)> Guess what? LLDB and SCE are > two of the debugger-tuning options for a reason. > > Show me another _real_ case of _real_ differences that matter to the > community, and we can talk about another debugger tuning option. > > > I am having a lot of trouble understanding how this is about what > > debuggers expect and not "ways of representing things". > > Sometimes there's not much difference in the result, although there > is a difference in how we think about it. > > > 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. > > (That sort of alternate proposal is way more useful than the straw-man > stuff you started out with. Just sayin'.) > > (Also incidentally, I see gcc 4.8.2 is emitting an explicit import of > anonymous namespaces, so that's becoming _less_ different over time.) > > In fact this is more or less how DwarfDebug operates now; there is a > pile (small pile, but still a pile) of individual feature flags that > get set various ways depending on target or command-line options. > The problem I'm looking at is that the defaults for a lot of these > things are based on target, which AFAICT is based on an out-of-date > assumption about how target correlates to debugger. > > I'm proposing to package up known sets of stuff that we're having to > contend with _today_ in a way that's easier to talk about and do > something about than the target-oriented mish-mash we have now. > > It's a whole lot simpler to say something like "FreeBSD implies LLDB" > instead of "FreeBSD implies accelerator tables and standard TLS opcode > and no pubnames or pubtypes." > > Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref > --lang-feature=move_ctor ..." than "-std=c++11"? > > > > 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. > > If it's meaningfully different, i.e. makes enough of a functional and/or > size difference, and it's an environment we collectively want to support, > and it's unreasonable to get the necessary effect some other way, then > sure, maybe we would want to invent a new tuning profile. > > But, if it doesn't meet that bar, I don't see why we'd want to. > --paulr > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/01df4660/attachment.html>
Robinson, Paul
2015-May-02 00:31 UTC
[LLVMdev] [cfe-dev] What does "debugger tuning" mean?
FWIW I'd be surprised if Apple's carrying much internal cost for LLVM's debug info. Hmm maybe. Adrian seemed awfully excited about the TLS opcode patch, though. --paulr From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Friday, May 01, 2015 5:11 PM To: Robinson, Paul Cc: Daniel Berlin; lldb-dev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) Subject: Re: [cfe-dev] [LLVMdev] What does "debugger tuning" mean? On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:> -----Original Message----- > From: Daniel Berlin [mailto:dberlin at dberlin.org<mailto:dberlin at dberlin.org>] > Sent: Friday, May 01, 2015 3:15 PM > To: Robinson, Paul > Cc: cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu> Developers (cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>); LLVM Developers > Mailing List (llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>); lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu> > Subject: Re: [LLVMdev] What does "debugger tuning" mean? > > On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul > <Paul_Robinson at playstation.sony.com<mailto: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".Different ways of describing things let us reason about them in different ways. Are Cartesian coordinates a reason to reject polar coordinates?> Debuggers change over time.Well, they're software too. They're allowed.> 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?Are all of these current supported Clang/LLVM environments? Are they suffering because Clang currently emits DWARF in ways that cause them problems, or that bloats the debug info unnecessarily? Are vendors carrying a pile of private patches to get LLVM to emit DWARF that looks like what their debugger wants? If the answer to these questions is Yes then my answer to your question is Sure, we could, if we find those differences to be important. I promise you that these things are true at Sony, and I would be astounded if it wasn't true for Apple. FWIW I'd be surprised if Apple's carrying much internal cost for LLVM's debug info. It was essentially built for ye olde GDB and even when I set about improving it I brought up an external buildbot for that workload to ensure it wasn't broken (& LLDB was built for LLVM's debug info output, so there's not much reason to expect that wouldn't work - the base class declaration's one of the only cases there that I know of - and yes, that's predicated on Darwin & should be predicated on LLDB as you're proposing) Guess what? LLDB and SCE are two of the debugger-tuning options for a reason. Show me another _real_ case of _real_ differences that matter to the community, and we can talk about another debugger tuning option.> I am having a lot of trouble understanding how this is about what > debuggers expect and not "ways of representing things".Sometimes there's not much difference in the result, although there is a difference in how we think about it.> 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.(That sort of alternate proposal is way more useful than the straw-man stuff you started out with. Just sayin'.) (Also incidentally, I see gcc 4.8.2 is emitting an explicit import of anonymous namespaces, so that's becoming _less_ different over time.) In fact this is more or less how DwarfDebug operates now; there is a pile (small pile, but still a pile) of individual feature flags that get set various ways depending on target or command-line options. The problem I'm looking at is that the defaults for a lot of these things are based on target, which AFAICT is based on an out-of-date assumption about how target correlates to debugger. I'm proposing to package up known sets of stuff that we're having to contend with _today_ in a way that's easier to talk about and do something about than the target-oriented mish-mash we have now. It's a whole lot simpler to say something like "FreeBSD implies LLDB" instead of "FreeBSD implies accelerator tables and standard TLS opcode and no pubnames or pubtypes." Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref --lang-feature=move_ctor ..." than "-std=c++11"?> 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.If it's meaningfully different, i.e. makes enough of a functional and/or size difference, and it's an environment we collectively want to support, and it's unreasonable to get the necessary effect some other way, then sure, maybe we would want to invent a new tuning profile. But, if it doesn't meet that bar, I don't see why we'd want to. --paulr _______________________________________________ cfe-dev mailing list cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150502/3d0c5bf6/attachment.html>
On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:>> -----Original Message----- >> From: Daniel Berlin [mailto:dberlin at dberlin.org] >> Sent: Friday, May 01, 2015 3:15 PM >> To: Robinson, Paul >> Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers >> Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu >> Subject: Re: [LLVMdev] What does "debugger tuning" mean? >> >> 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". > > Different ways of describing things let us reason about them in different > ways. Are Cartesian coordinates a reason to reject polar coordinates? >Paul. I'm trying to understand why you've chosen the design you have. Given that what you are designing is something that is likely to have to be supported for a pretty long time, it makes sense to make sure that design is the right one for the use case you are trying to achieve.>> Debuggers change over time. > > Well, they're software too. They're allowed. > >> 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? > > Are all of these current supported Clang/LLVM environments?Plenty of them are?> Are they > suffering because Clang currently emits DWARF in ways that cause them > problems, or that bloats the debug info unnecessarily?Yes, sure.> Are vendors > carrying a pile of private patches to get LLVM to emit DWARF that looks > like what their debugger wants? If the answer to these questions is > Yes then my answer to your question is Sure, we could, if we find > those differences to be important.This does not do a lot to explain why your design choice of "debugger names" over "features" makes sense.> > I promise you that these things are true at Sony, and I would be > astounded if it wasn't true for Apple. Guess what? LLDB and SCE are > two of the debugger-tuning options for a reason.What does this have to do anything? If they were just features, you wouldn't have to define *any of these options*.> > Show me another _real_ case of _real_ differences that matter to the > community, and we can talk about another debugger tuning option.Again, i'm asking you to define why "debugger target" is the right abstraction for what you are trying to achieve, when history has shown 1. Feature tests/description have worked better for compiler differentiation than target "gcc 2.95" 2. The same is highly likely to be true of debuggers. Particularly in light of the fact that what i'm suggesting you do does not in any way prevent or change what you want to achieve, but simply abstract it in a way that requires no work on the part of clang/llvm to get any particular subset of features they want for their debugger. IE people do not have to change source in response to debugger changes. In response, you have mostly just told me "a lot of users are in pain right now".> >> I am having a lot of trouble understanding how this is about what >> debuggers expect and not "ways of representing things". > > Sometimes there's not much difference in the result, although there > is a difference in how we think about it. > >> 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. > > (That sort of alternate proposal is way more useful than the straw-man > stuff you started out with. Just sayin'.)Seriously? It's not a strawman. I am asking you *why you have designed it this way when plenty of other abstractions, at face value, seem to make more sense to me"> > (Also incidentally, I see gcc 4.8.2 is emitting an explicit import of > anonymous namespaces, so that's becoming _less_ different over time.) > > In fact this is more or less how DwarfDebug operates now; there is a > pile (small pile, but still a pile) of individual feature flags that > get set various ways depending on target or command-line options. > The problem I'm looking at is that the defaults for a lot of these > things are based on target, which AFAICT is based on an out-of-date > assumption about how target correlates to debugger. > > I'm proposing to package up known sets of stuff that we're having to > contend with _today_ in a way that's easier to talk about and do > something about than the target-oriented mish-mash we have now.> > It's a whole lot simpler to say something like "FreeBSD implies LLDB" > instead of "FreeBSD implies accelerator tables and standard TLS opcode > and no pubnames or pubtypes." > > Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref > --lang-feature=move_ctor ..." than "-std=c++11"?The lang-feature stuff is exactly how people test for what level of c++11 support something has. -std=c++11, in fact, means different things to different compilers, and thus, has in fact *not* provided a good abstraction for people trying to say "i want to be able to compile anything that is standard c++11". Why do you expect debuggers to be different here? Honestly. I'm really just trying to understand why you think debuggers are going to turn out different. This is despite the fact that C++11 is in fact a standard. If there was "standard gdb", yes, it may make sense for llvm to *try* have -debugger-std=gdb. But there *is no standard gdb*. So i'm trying to understand why you are tying you design to the notion that you can have a "gdb debugger tuning", instead of having a list of features, and then having something that understands what the user wants (like your IDE, or even a driver), set the feature flags that make sense for whatever profiles you care to define.> > >> 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. > > If it's meaningfully different, i.e. makes enough of a functional and/or > size difference, and it's an environment we collectively want to support, > and it's unreasonable to get the necessary effect some other way, then > sure, maybe we would want to invent a new tuning profile. > > But, if it doesn't meet that bar, I don't see why we'd want to.None of this has been particularly helpful in understanding why you've made the design tradeoffs you have. I'm not calling your design good or bad. I'm trying to understand why you have chosen this set of things from among the various alternatives. Is there a document, a thread, or anything that goes through the various alternatives you've considered before you arrived at this one?> --paulr >
On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote:> > -----Original Message----- > > From: Daniel Berlin [mailto:dberlin at dberlin.org] > > Sent: Friday, May 01, 2015 3:15 PM > > To: Robinson, Paul > > Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM > Developers > > Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu > > Subject: Re: [LLVMdev] What does "debugger tuning" mean? > > > > 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". > > Different ways of describing things let us reason about them in different > ways. Are Cartesian coordinates a reason to reject polar coordinates? > > > Debuggers change over time. > > Well, they're software too. They're allowed. > > > 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? > > Are all of these current supported Clang/LLVM environments? Are they > suffering because Clang currently emits DWARF in ways that cause them > problems, or that bloats the debug info unnecessarily? Are vendors > carrying a pile of private patches to get LLVM to emit DWARF that looks > like what their debugger wants? If the answer to these questions is > Yes then my answer to your question is Sure, we could, if we find > those differences to be important. > > I promise you that these things are true at Sony, and I would be > astounded if it wasn't true for Apple. Guess what? LLDB and SCE are > two of the debugger-tuning options for a reason. > > Show me another _real_ case of _real_ differences that matter to the > community, and we can talk about another debugger tuning option. > > > I am having a lot of trouble understanding how this is about what > > debuggers expect and not "ways of representing things". > > Sometimes there's not much difference in the result, although there > is a difference in how we think about it. > > > 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. > > (That sort of alternate proposal is way more useful than the straw-man > stuff you started out with. Just sayin'.) > > (Also incidentally, I see gcc 4.8.2 is emitting an explicit import of > anonymous namespaces, so that's becoming _less_ different over time.) > > In fact this is more or less how DwarfDebug operates now; there is a > pile (small pile, but still a pile) of individual feature flags that > get set various ways depending on target or command-line options. > The problem I'm looking at is that the defaults for a lot of these > things are based on target, which AFAICT is based on an out-of-date > assumption about how target correlates to debugger. > > I'm proposing to package up known sets of stuff that we're having to > contend with _today_ in a way that's easier to talk about and do > something about than the target-oriented mish-mash we have now. > > It's a whole lot simpler to say something like "FreeBSD implies LLDB" > instead of "FreeBSD implies accelerator tables and standard TLS opcode > and no pubnames or pubtypes." > > Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref > --lang-feature=move_ctor ..." than "-std=c++11"? >Is there a reason that we couldn't implement "--debugger-target=lldb" as syntax sugar for "--debugger-feature=acceleratortables --debugger-feature=standardtlsopcode --debugger-feature=no-pubnames --debugger-feature=no-pubtypes"? I'm not strongly convinced that we would necessarily need to expose the --debugger-feature flag to users (or at all on the command line), if that's what is bothering you. But at some point inside the code there needs to be an explicit factorization of the different "debugger targets" into what would be individual --debugger-feature options, so that it is easy to describe new debugger targets. -- Sean Silva> > > > 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. > > If it's meaningfully different, i.e. makes enough of a functional and/or > size difference, and it's an environment we collectively want to support, > and it's unreasonable to get the necessary effect some other way, then > sure, maybe we would want to invent a new tuning profile. > > But, if it doesn't meet that bar, I don't see why we'd want to. > --paulr > > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/49ad4632/attachment.html>
Robinson, Paul
2015-May-04 18:11 UTC
[LLVMdev] [cfe-dev] What does "debugger tuning" mean?
Hi Daniel, your post came across as snarkier than that, apologies for the mis-interpretation. My design tries to improve on a not-very-smooth situation today, where there is already "tuning" but it is based largely on the target—even though we know for a fact that target is not always a good proxy for choosing the expected debugger. By making the expected debugger explicit, we separate these concerns, and clarify the intent. The existing tuning has default behavior clearly intended to support GDB, LLDB, and now the SCE (PS4) debugger; therefore, my proposal made those three cases explicit. If you have examples of other debuggers on other target, where emitting different subsets of DWARF would be beneficial, and those subsets don't align with GDB, LLDB, or SCE debugger, then more cases might be appropriate. I am not inclined to propose hypothetical cases, but if you have actual examples then that would be very helpful. Note that we are not talking about whether the debugger is different. We are talking about whether the debug-info ought to be different. Saying that some target has a different debugger is not sufficient. If HP's wacky GDB, or OpenVMS Debug, or whatever, are happy with the DWARF we provide now, then there's no point to defining a new debugger-tuning case for them. Regarding fine-grained feature-oriented command-line control, I thought I had said that in fact most of the specific cases already have that, although the naming isn't as consistent as one might like. All of that folds down into individual feature-flags within the DwarfDebug class, whose constructor currently bases its defaults on the target and in my design would base its defaults on the debugger-tuning parameter. Then the methods that actually emit DWARF look at the feature flags, not at the tuning parameter. This situation is very close to what Sean said, where the debugger-tuning parameter provides a prepackaged set of feature-flags defaults. Any of these (that have their own command-line option) would be superseded by the explicit command-line option. In some cases these individual features are exposed all the way out to the user command line. This is especially true when you're talking about emitting or omitting entire sections, or a major less-well-supported feature like type units. I am not eager to expose the more fiddly-bit things on the command line, because it's hard to envision any real value to it. So, in those terms, what would the initial state of things be? GDB = -generate-dwarf-pub-sections; (no command-line option) UseGNUTLSOpcode LLDB = -dwarf-accel-tables SCE = (none of the above) I anticipate adding a new feature-flag, something like "-dwarf-linkage-names" to GDB and LLDB but not SCE, because SCE has no use for them. I anticipate adding a new feature-flag to control the DW_AT_APPLE_* attributes, although whether its default should be target-based or tuning-based is TBD (I don't know the intended consumer of these attributes). I anticipate changing the default for "-generate-arange-section" from always-false to Target==PS4CPU. This is not under tuning control because the consumer of it on PS4 is not the debugger. In fact the default might end up being set in the driver, because there is an existing user command-line option for this. If somebody wanted a command-line flag for UseGNUTLSOpcode, patches welcome. If people want to bikeshed the backend command-line option names, that's a different discussion. There are more existing options than the ones I've mentioned here; the others are default-off and under user command-line control. Harmonizing all of them would be its own mini-project. Does that help? --paulr From: Sean Silva [mailto:chisophugis at gmail.com] Sent: Friday, May 01, 2015 6:21 PM To: Robinson, Paul Cc: Daniel Berlin; lldb-dev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) Subject: Re: [cfe-dev] [LLVMdev] What does "debugger tuning" mean? On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:> -----Original Message----- > From: Daniel Berlin [mailto:dberlin at dberlin.org<mailto:dberlin at dberlin.org>] > Sent: Friday, May 01, 2015 3:15 PM > To: Robinson, Paul > Cc: cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu> Developers (cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>); LLVM Developers > Mailing List (llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>); lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu> > Subject: Re: [LLVMdev] What does "debugger tuning" mean? > > On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul > <Paul_Robinson at playstation.sony.com<mailto: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".Different ways of describing things let us reason about them in different ways. Are Cartesian coordinates a reason to reject polar coordinates?> Debuggers change over time.Well, they're software too. They're allowed.> 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?Are all of these current supported Clang/LLVM environments? Are they suffering because Clang currently emits DWARF in ways that cause them problems, or that bloats the debug info unnecessarily? Are vendors carrying a pile of private patches to get LLVM to emit DWARF that looks like what their debugger wants? If the answer to these questions is Yes then my answer to your question is Sure, we could, if we find those differences to be important. I promise you that these things are true at Sony, and I would be astounded if it wasn't true for Apple. Guess what? LLDB and SCE are two of the debugger-tuning options for a reason. Show me another _real_ case of _real_ differences that matter to the community, and we can talk about another debugger tuning option.> I am having a lot of trouble understanding how this is about what > debuggers expect and not "ways of representing things".Sometimes there's not much difference in the result, although there is a difference in how we think about it.> 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.(That sort of alternate proposal is way more useful than the straw-man stuff you started out with. Just sayin'.) (Also incidentally, I see gcc 4.8.2 is emitting an explicit import of anonymous namespaces, so that's becoming _less_ different over time.) In fact this is more or less how DwarfDebug operates now; there is a pile (small pile, but still a pile) of individual feature flags that get set various ways depending on target or command-line options. The problem I'm looking at is that the defaults for a lot of these things are based on target, which AFAICT is based on an out-of-date assumption about how target correlates to debugger. I'm proposing to package up known sets of stuff that we're having to contend with _today_ in a way that's easier to talk about and do something about than the target-oriented mish-mash we have now. It's a whole lot simpler to say something like "FreeBSD implies LLDB" instead of "FreeBSD implies accelerator tables and standard TLS opcode and no pubnames or pubtypes." Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref --lang-feature=move_ctor ..." than "-std=c++11"? Is there a reason that we couldn't implement "--debugger-target=lldb" as syntax sugar for "--debugger-feature=acceleratortables --debugger-feature=standardtlsopcode --debugger-feature=no-pubnames --debugger-feature=no-pubtypes"? I'm not strongly convinced that we would necessarily need to expose the --debugger-feature flag to users (or at all on the command line), if that's what is bothering you. But at some point inside the code there needs to be an explicit factorization of the different "debugger targets" into what would be individual --debugger-feature options, so that it is easy to describe new debugger targets. -- Sean Silva> 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.If it's meaningfully different, i.e. makes enough of a functional and/or size difference, and it's an environment we collectively want to support, and it's unreasonable to get the necessary effect some other way, then sure, maybe we would want to invent a new tuning profile. But, if it doesn't meet that bar, I don't see why we'd want to. --paulr _______________________________________________ cfe-dev mailing list cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150504/29370f10/attachment.html>