[lldb-dev] [Bug 28293] New: LLDB can't find split debug info if the debuggee has been moved form build directory
https://llvm.org/bugs/show_bug.cgi?id=28293 Bug ID: 28293 Summary: LLDB can't find split debug info if the debuggee has been moved form build directory Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: vadi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified (This situation often arises when build servers are employed) I think this happens because LLDB simply takes DW_AT_comp_dir at the face value here: https://github.com/llvm-mirror/lldb/blob/876d71dc6c37f23c8ae9d219705d06c6def3f354/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L1778-1794 There should be a way to remap debug info paths similarly to what is done for source with 'target.source-map'. I would even argue that it should be the same setting for both. Another good candidate seems to be the 'target.debug-file-search-paths' setting. LLDB could probe each of these directories (also probably the directory where the debuggee is located) combined with the value of DW_AT_GNU_dwo_name. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg wrote: > Breaking this out into a separate thread since it's kind of a separate > issue, and to make sure people see it. > > If you have opinions on this, please chime in. I'd like to collect as > many arguments here as possible to make a good decision. The main > contestants are 4.0 and 3.10, and I've seen folks being equally > surprised by both. Thanks everyone for chiming in. Please correct me if I misrepresent your opinion here, but I need to try and summarize this thread for my own sanity: The thread started out with lots of support for 3.10, the reasoning being roughly that we shouldn't bump the major version number unless we want to signify major change (Mehdi, Hal, Blaikie, Saleem, Chandler, Anton, Eric, Aaron, Sean, Vikram). Richard suggested that since we do time-based rather than feature-based releases, the distinction between a release with or without major changes is arbitrary, and we should move to a scheme where we update the major version number on each release (4.0, 5.0, etc.) with minor releases in between (4.1, 5.1, ..). Chris advocated for "keep adding 0.1 to each major release" (in the decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else suggest this. "I do not think it is reasonable at all to go to '3.10' after '3.9', because we will never get to '4.0'." Chris then expressed support for alternatively just incrementing the major version each time, as Richard suggested, but starting at 40. Rafael expressed support for the above, but starting at 4.0: "It is simply not worth the time to try to figure out what is 'major' in a project with so many different uses." Chandler said he didn't like Chris's "keep adding 0.1 to each major release" scheme: "we shouldn't just go from 3.9 to 4.0 because of some decimal correspondence", and said he was open to either going to 3.10 with the current major/minor split, or if we don't want that, use Richard's suggestion. Michael pointed out that if we do change the numbering scheme, changing the binary compatibility guarantee to something time-based isn't equivalent to what we currently have. So, it seems we're at an impasse with several folks in favour of 3.10, Chris speaking out strongly against it, and Richard's option which has some traction and which no one's disagreed with so far, but which would be a bigger change. I'll have a think about this over the weekend. Cheers, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Fri, Jun 24, 2016 at 4:41 PM, Hans Wennborg via llvm-dev
wrote:
> Richard suggested that since we do time-based rather than
> feature-based releases, the distinction between a release with or
> without major changes is arbitrary, and we should move to a scheme
> where we update the major version number on each release (4.0, 5.0,
> etc.) with minor releases in between (4.1, 5.1, ..).
If we are truly committed to doing time-based releases, we can switch
to time-based version numbers, Year.Month, for example, if we were to
release in June it would be 16.06. We can use an extra digit for
minor releases.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j*/
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Fri, Jun 24, 2016 at 5:43 PM, Dmitri Gribenko via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> On Fri, Jun 24, 2016 at 4:41 PM, Hans Wennborg via llvm-dev
> wrote:
> > Richard suggested that since we do time-based rather than
> > feature-based releases, the distinction between a release with or
> > without major changes is arbitrary, and we should move to a scheme
> > where we update the major version number on each release (4.0, 5.0,
> > etc.) with minor releases in between (4.1, 5.1, ..).
>
> If we are truly committed to doing time-based releases, we can switch
> to time-based version numbers, Year.Month, for example, if we were to
> release in June it would be 16.06. We can use an extra digit for
> minor releases.
>
This would mirror other projects doing the same, so there is precedent.
Although radically different from the current model, I think it has some
merit. When people report bugs with 3.1, its actually hard to estimate how
it is (roughly estimating it via ~6mo release cycle does really work).
This would certainly make it easier.
Its a good alternative though it does mean that we no longer have the
ability to indicate a major shift. However as Chris already pointed out,
LLVM is much more stable these days and perhaps worrying about major shifts
which are unseen is looking for a problem to solve rather than solving a
problem at hand.
+1 on this suggestion.
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
> On Jun 24, 2016, at 7:41 PM, Hans Wennborg wrote: > > On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg wrote: >> Breaking this out into a separate thread since it's kind of a separate >> issue, and to make sure people see it. >> >> If you have opinions on this, please chime in. I'd like to collect as >> many arguments here as possible to make a good decision. The main >> contestants are 4.0 and 3.10, and I've seen folks being equally >> surprised by both. > > Thanks everyone for chiming in. > > Please correct me if I misrepresent your opinion here, but I need to > try and summarize this thread for my own sanity: > > The thread started out with lots of support for 3.10, the reasoning > being roughly that we shouldn't bump the major version number unless > we want to signify major change (Mehdi, Hal, Blaikie, Saleem, > Chandler, Anton, Eric, Aaron, Sean, Vikram). Since I’m mentioned here in support of 3.10, I’d like to correct by repeating what I wrote previously in this thread: "To clarify my point: I don't have a particular opinion about bumping the major number for whatever other reason than breaking the compatibility, but I'd probably suggest that we rewrite the compatibility policy to say something like "The current LLVM version support loading any bitcode since version 3.0”.” Otherwise either Rafael last proposal (starting at 4.0 and +1 for every release), or Dmitri (“ubuntu-like” date-based numbering) are perfectly fine for me. — Mehdi > > Richard suggested that since we do time-based rather than > feature-based releases, the distinction between a release with or > without major changes is arbitrary, and we should move to a scheme > where we update the major version number on each release (4.0, 5.0, > etc.) with minor releases in between (4.1, 5.1, ..). > > Chris advocated for "keep adding 0.1 to each major release" (in the > decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else > suggest this. "I do not think it is reasonable at all to go to '3.10' > after '3.9', because we will never get to '4.0'." > > Chris then expressed support for alternatively just incrementing the > major version each time, as Richard suggested, but starting at 40. > > Rafael expressed support for the above, but starting at 4.0: "It is > simply not worth the time to try to figure out what is 'major' in a > project with so many different uses." > > Chandler said he didn't like Chris's "keep adding 0.1 to each major > release" scheme: "we shouldn't just go from 3.9 to 4.0 because of some > decimal correspondence", and said he was open to either going to 3.10 > with the current major/minor split, or if we don't want that, use > Richard's suggestion. > > Michael pointed out that if we do change the numbering scheme, > changing the binary compatibility guarantee to something time-based > isn't equivalent to what we currently have. > > > > So, it seems we're at an impasse with several folks in favour of 3.10, > Chris speaking out strongly against it, and Richard's option which has > some traction and which no one's disagreed with so far, but which > would be a bigger change. > > I'll have a think about this over the weekend. > > Cheers, > Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
