Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio?
On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via cfe-dev
wrote:
>
> This has been on my mind for quite some time, but recently it's been popping
> up more and more seeing some of the issues people have run into.
>
> Before people get the wrong idea, let me make one thing clear. **I am not
> proposing we stop supporting the CMake Visual Studio generator. I am only
> proposing we stop supporting actually compiling with the generated project**.
> Yes the distinction is important, and I'll elaborate more on why later.
> First though, here are some of the issues with the VS generator:
>
> 1) Using MSBuild is slower than Ninja.
> 2) Unless you remember to pass -Thost=x64 on the command line, you won't be
> able to successfully build. We can (and have) updated the documentation to
> indicate this, but it's not intuitive and still bites people because for some
> reason this is not the default.
> 3) Even if you do pass -Thost=x64 to CMake, it will apparently still fail
> sometimes. See this thread for details:
> http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html. It seems
> the parallel build scheduler does not do a good job and can bring a machine
> down. This is not the first time though, every couple of months there's a
> thread about how building or running tests from within VS doesn't work.
> 4) Supporting it is a continuous source of errors and mistakes when writing
> tests. The VS generator outputs a project which can build Debug / Release
> with a single project. This means that `CMAKE_BUILD_TYPE=Debug` is a no-op
> on this generator. The reason this matters for the test suite is because
> `${CMAKE_CURRENT_BINARY_DIR}` isn't sufficient to identify the location of
> the binaries. You need `${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}`
> instead.
>
> There is a continuous source of problems in our CMake [1, 2, 3, 4, 5]. It
> also affects tests, and every time someone adds a new lit site configuration,
> they have to remember to add this magic block of code:
>
> # Support substitution of the tools_dir with user parameters. This is
> # used when we can't determine the tool dir at configuration time.
> try:
> config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
> config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
> except KeyError:
> e = sys.exc_info()[1]
> key, = e.args
> lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" %
> (key,key))
>
> to the file (even though only about 2 people actually understand what this
> does), which has caused problems several times.
>
> 5) VSCode and Visual Studio both support opening CMake projects directly now,
> which bypasses MSBuild. I don't know how well Visual Studio supports LLVM's
> CMake, but the last time I tried it with VSCode on Linux it worked fine.
>
>
>
> I mentioned earlier that the distinction between not *building* with a
> VS-generated project and not supporting the VS generator is important.
>
> I don't want to speak for everyone, but I believe that *most* people use the
> VS generator because they want IDE support for their projects. They want to
> be able to browse code, hit F5 to debug, F9 to set breakpoints, etc. They
> don't necessarily care that Ctrl+Shift+B is how the code is generated versus
> some other incantation. I'm asserting that it's possible to still have all
> the things people actually want from the VS generator without actually
> building from inside of VS. In fact, I've been doing this for several years.
> The workflow is:
>
> 1) Run CMake twice, generating to separate output directories. Once using -G
> "Visual Studio 15 2017" and once using -G Ninja, each to different
> directories.
>
> 2) Open the VS one. You have full IDE support.
>
> 3) Instead of hitting Ctrl+Shift+B to build, have a command prompt window
> open and type ninja. Wait for it to complete. If you want to you can make a
> custom tool command in Visual Studio so that you can access this from a
> keyboard shortcut.
>
> 4) When you want to debug, set your startup project (as you normally would),
> right click and hit properties, go to Debugging, change Command from
> $(TargetPath) to to debug>.
>
> 5) Hit F5.
>
> In short, with only 2 simple additional steps (run CMake an extra time, and
> type a path into a window), people can have the exact workflow they are used
> to, plus faster builds, minus all of the problems and complexities associated
> with building from within VS.
>
> And we can simplify our CMake logic and lit configuration files as well.
As someone who almost exclusively uses MSVC and not Ninja on Windows,
I'll have to try this workflow out to see how it works for me in
practice. Unfortunately, I won't really be able to test it for a few
weeks.
However, I'm concerned by the idea that we want to drop support for
building with the standard workflow in a toolchain that's as popular
as MSVC is. "Here's a simp
Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio?
Thanks for raising this.
This is a topic I've been interested in for a while too, as I've had to do
a few of those lite.site.cfg fix-ups that you mention (in fact I have one
sitting unreviewed at https://reviews.llvm.org/D40522 although I've not
pinged it in a long time so I'll need to double check that it's still an
issue). There are also other issues. For
example LLVM_ENABLE_ABI_BREAKING_CHECKS is implemented in such a way that
by default the value is defined at CMake time based on the value of
LLVM_ENABLE_ASSERTIONS which gets confusing with the Visual Studio
generator where the value of LLVM_ENABLE_ASSERTIONS does not necessarily
correspond to whether assertions are enabled or not.
As I understand it, what you're proposing is to not support building for
any configs that return true for GENERATOR_IS_MULTI_CONFIG. This includes
all of the Visual Studio generators, but also the Xcode generator. I'm not
an Xcode user. Does anyone make use of that generator or is it entirely
replaced in practice by single-config generators, i.e. Ninja?
We're still using the Visual Studio generators in production at Sony at
the moment. This is largely because until recently they were actually
faster than Ninja for us due to the availability of distributed builds on
our network. We've recently patched in support for our system into our
private branch of Ninja now so in theory it should be faster/on-par again
but we've not yet pulled the trigger on making them the default. If
there's consensus that this is the way forward, then we'll definitely need
some time to make the change internally. I'm only speaking personally in
this reply as I'll need to discuss with the rest of the team before we can
reach a position, but basically I wouldn't want the conclusion of this
thread to be "No dissenting voices, so here's an immediate patch to remove
support!"
I've not tried the workflow you describe. I'll try it out in the coming
days to see how it works for me. My main concerns are:
* How far will it raise the barrier of entry to new developers? My
impression is that a lot of students coming to LLVM for the first time,
first build out of the box with Visual Studio before later discovering this
magical thing called Ninja that will speed things up. Potentially this
could be mitigated with good enough documentation in the getting started
guide I expect.
* LLVM's CMake is super-slow on Windows, and we'd need to run it twice
whenever there are project changes. This could be a significant drawback
in the proposed workflow but I'll need to try it before I can say that for
sure.
* My muscle memory causing repeated Ctrl+Shift+B :-). I wonder if we could
add a PRE_BUILD custom target conditional on GENERATOR_IS_MULTI_CONFIG to
automatically fail any builds with a useful help message.
If the decision is that we continue supporting these generators, then at
the very least we should look into adding a buildbot configured to use one
of the Visual Studio Generators rather than ninja so that issues get
spotted on commit.
-Greg
On Sun, 7 Oct 2018 at 21:51, Zachary Turner via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> This has been on my mind for quite some time, but recently it's been
> popping up more and more seeing some of the issues people have run into.
>
> Before people get the wrong idea, let me make one thing clear. **I am not
> proposing we stop supporting the CMake Visual Studio generator. I am only
> proposing we stop supporting actually compiling with the generated
> project**. Yes the distinction is important, and I'll elaborate more on
> why later. First though, here are some of the issues with the VS generator:
>
> 1) Using MSBuild is slower than Ninja.
> 2) Unless you remember to pass -Thost=x64 on the command line, you won't
> be able to successfully build. We can (and have) updated the documentation
> to indicate this, but it's not intuitive and still bites people because for
> some reason this is not the default.
> 3) Even if you do pass -Thost=x64 to CMake, it will apparently still fail
> sometimes. See this thread for details:
> http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html. It
> seems the parallel build scheduler does not do a good job and can bring a
> machine down. This is not the first time though, every couple of months
> there's a thread about how building or running tests from within VS doesn't
> work.
> 4) Supporting it is a continuous source of errors and mistakes when
> writing tests. The VS generator outputs a project which can build Debug /
> Release with a single project. This means that `CMAKE_BUILD_TYPE=Debug` is
> a no-op on this generator. The reason this matters for the test suite is
> because `${CMAKE_CURRENT_BINARY_DIR}` isn't sufficient to identify the
> location of the binaries. You need
> `${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}`
> instead.
>
> There is a continuous source of problems in our CMake [1, 2, 3, 4, 5]. It
> also affects tests, an
Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio?
Yes i listed 5 steps, but 2 of them (#2 and #5) are exactly what you
already do.
#1 I only actually do every couple of weeks, which is an improvement over
building inside VS. when you build inside vs you have to close and reopen
the solution every time you sync, which is really slow. You don’t actually
have to regenerate the ide solution unless you need to edit a file that was
added, which is rare. I’ve gone several months without regenerating the vs
solution.
#3 is not *that* much different than what we already do. 6 of one, half
dozen of another.
#4 is the only real diff, if you build from the ide this just works, with
this workflow there’s 1 extra step. But you only really have to do it the
first time.
On Mon, Oct 8, 2018 at 7:35 AM Aaron Ballman wrote:
> On Sun, Oct 7, 2018 at 4:51 PM Zachary Turner via cfe-dev
> wrote:
> >
> > This has been on my mind for quite some time, but recently it's been
> popping up more and more seeing some of the issues people have run into.
> >
> > Before people get the wrong idea, let me make one thing clear. **I am
> not proposing we stop supporting the CMake Visual Studio generator. I am
> only proposing we stop supporting actually compiling with the generated
> project**. Yes the distinction is important, and I'll elaborate more on
> why later. First though, here are some of the issues with the VS generator:
> >
> > 1) Using MSBuild is slower than Ninja.
> > 2) Unless you remember to pass -Thost=x64 on the command line, you won't
> be able to successfully build. We can (and have) updated the documentation
> to indicate this, but it's not intuitive and still bites people because for
> some reason this is not the default.
> > 3) Even if you do pass -Thost=x64 to CMake, it will apparently still
> fail sometimes. See this thread for details:
> http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html. It
> seems the parallel build scheduler does not do a good job and can bring a
> machine down. This is not the first time though, every couple of months
> there's a thread about how building or running tests from within VS doesn't
> work.
> > 4) Supporting it is a continuous source of errors and mistakes when
> writing tests. The VS generator outputs a project which can build Debug /
> Release with a single project. This means that `CMAKE_BUILD_TYPE=Debug` is
> a no-op on this generator. The reason this matters for the test suite is
> because `${CMAKE_CURRENT_BINARY_DIR}` isn't sufficient to identify the
> location of the binaries. You need
> `${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}` instead.
> >
> > There is a continuous source of problems in our CMake [1, 2, 3, 4, 5].
> It also affects tests, and every time someone adds a new lit site
> configuration, they have to remember to add this magic block of code:
> >
> > # Support substitution of the tools_dir with user parameters. This is
> > # used when we can't determine the tool dir at configuration time.
> > try:
> > config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
> > config.llvm_shlib_dir = config.llvm_shlib_dir % lit_config.params
> > except KeyError:
> > e = sys.exc_info()[1]
> > key, = e.args
> > lit_config.fatal("unable to find %r parameter, use
> '--param=%s=VALUE'" % (key,key))
> >
> > to the file (even though only about 2 people actually understand what
> this does), which has caused problems several times.
> >
> > 5) VSCode and Visual Studio both support opening CMake projects directly
> now, which bypasses MSBuild. I don't know how well Visual Studio supports
> LLVM's CMake, but the last time I tried it with VSCode on Linux it worked
> fine.
> >
> >
> >
> > I mentioned earlier that the distinction between not *building* with a
> VS-generated project and not supporting the VS generator is important.
> >
> > I don't want to speak for everyone, but I believe that *most* people use
> the VS generator because they want IDE support for their projects. They
> want to be able to browse code, hit F5 to debug, F9 to set breakpoints,
> etc. They don't necessarily care that Ctrl+Shift+B is how the code is
> generated versus some other incantation. I'm asserting that it's possible
> to still have all the things people actually want from the VS generator
> without actually building from inside of VS. In fact, I've been doing this
> for several years. The workflow is:
> >
> > 1) Run CMake twice, generating to separate output directories. Once
> using -G "Visual Studio 15 2017" and once using -G Ninja, each to different
> directories.
> >
> > 2) Open the VS one. You have full IDE support.
> >
> > 3) Instead of hitting Ctrl+Shift+B to build, have a command prompt
> window open and type ninja. Wait for it to complete. If you want to you
> can make a custom tool command in Visual Studio so that you can access this
> from a keyboard shortcut.
> >
> > 4) When you want to debug, set your startup project (as you normally
> would), right click and hit prope
Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio?
> (in fact I have one sitting unreviewed at https://reviews.llvm.org/D40522 > although >> I've not pinged it in a long time so I'll need to double check that it's >> still an issue). >> > Actually, ignore that. It's a slightly different issue that I had mismembered as being related to https://reviews.llvm.org/D36263 and https://reviews.llvm.org/D38471 which I also worked on just prior to taking paternity leave! ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio?
On Mon, Oct 8, 2018 at 7:42 AM Greg Bedwell wrote: > Thanks for raising this. > > This is a topic I've been interested in for a while too, as I've had to do > a few of those lite.site.cfg fix-ups that you mention (in fact I have one > sitting unreviewed at https://reviews.llvm.org/D40522 although I've not > pinged it in a long time so I'll need to double check that it's still an > issue). There are also other issues. For > example LLVM_ENABLE_ABI_BREAKING_CHECKS is implemented in such a way that > by default the value is defined at CMake time based on the value of > LLVM_ENABLE_ASSERTIONS which gets confusing with the Visual Studio > generator where the value of LLVM_ENABLE_ASSERTIONS does not necessarily > correspond to whether assertions are enabled or not. > > As I understand it, what you're proposing is to not support building for > any configs that return true for GENERATOR_IS_MULTI_CONFIG. This includes > all of the Visual Studio generators, but also the Xcode generator. I'm not > an Xcode user. Does anyone make use of that generator or is it entirely > replaced in practice by single-config generators, i.e. Ninja? > I haven't heard of anyone using the Xcode generated project. In fact, LLDB maintains its own hand-created Xcode project precisely because the CMake one is considered "unusable". That said, I don't personally use Xcode or a Mac, so I can't speak for if anyone else might be using the Xcode generator. > > We're still using the Visual Studio generators in production at Sony at > the moment. This is largely because until recently they were actually > faster than Ninja for us due to the availability of distributed builds on > our network. We've recently patched in support for our system into our > private branch of Ninja now so in theory it should be faster/on-par again > but we've not yet pulled the trigger on making them the default. If > there's consensus that this is the way forward, then we'll definitely need > some time to make the change internally. I'm only speaking personally in > this reply as I'll need to discuss with the rest of the team before we can > reach a position, but basically I wouldn't want the conclusion of this > thread to be "No dissenting voices, so here's an immediate patch to remove > support!" > There's a patch up right now to add support for /MP. https://reviews.llvm.org/D52193. In theory this should also help unless you have your own distributed build system. I'm curious what was actually faster though. I've found hitting Ctrl+Shift+B from within Visual Studio to be much slower, but it seems like a lot of that time is going to MSBuild resolving dependencies and stuff. Like it sometimes takes over 30 seconds before it even starts doing *anything*. > > I've not tried the workflow you describe. I'll try it out in the coming > days to see how it works for me. My main concerns are: > > * How far will it raise the barrier of entry to new developers? My > impression is that a lot of students coming to LLVM for the first time, > first build out of the box with Visual Studio before later discovering this > magical thing called Ninja that will speed things up. Potentially this > could be mitigated with good enough documentation in the getting started > guide I expect. > There's a couple of ways we can mitigate this. We can print a warning when using the VS generator, and we can update the getting started guide. But I'm not sure it will raise the barrier of entry much, if at all. Right now new developers are struggling with building and running even with VS. Every couple of weeks there's posts about how the test suite wouldn't run, or something is running out of heap space, or they forgot to use -Thost=x64. > > * LLVM's CMake is super-slow on Windows, and we'd need to run it twice > whenever there are project changes. This could be a significant drawback > in the proposed workflow but I'll need to try it before I can say that for > sure. > I mentioned this in my response to Aaron, but just to re-iterate here, you only ever need to run CMake on the VS project if you actually want to edit a file that has been added, which is pretty rare. I have gone several months without re-generating and it works fine. This is actually a big improvement over the VS-generator-only workflow. FWIW, my experience is that the Ninja generator is at least twice as fast as the CMake generator. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio?
On Mon, Oct 8, 2018 at 11:54 AM Stephen Kelly via cfe-dev < cfe-...@lists.llvm.org> wrote: > > > 3) Even if you do pass -Thost=x64 to CMake, it will apparently still > > fail sometimes. See this thread for details: > > http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html. It > > seems the parallel build scheduler does not do a good job and can bring > > a machine down. This is not the first time though, every couple of > > months there's a thread about how building or running tests from within > > VS doesn't work. > > I don't know any more about this. It would be good to know more than > that it can "apparently fail sometimes". > > Sadly that's part of the problem. Very few people actually use the Visual Studio generator for building, so a lot of times when we get people with issues, nobody knows how to help (or the person that does know doesn't see the thread). So they get a response like "hmm, not many people actually use that workflow, can you try this instead?" I feel bad when I can't help, and that's part of why I made this proposal in the first place, because fewer supported options in the configuration matrix means people are more likely to find someone who understands the problem when something goes wrong. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio?
> On Oct 8, 2018, at 8:09 AM, Zachary Turner via lldb-dev > wrote: > > I haven't heard of anyone using the Xcode generated project. In fact, LLDB > maintains its own hand-created Xcode project precisely because the CMake one > is considered "unusable". That said, I don't personally use Xcode or a Mac, > so I can't speak for if anyone else might be using the Xcode generator. > All of Xcode's smart code comprehension relies on the clang index built from the project. Xcode uses the project's build rules to construct the index. Apparently the cmake generated Xcode project doesn't communicate the info on how to build the project and thus the index to Xcode in a way it can use. I haven't tried it recently for lldb (I don't think anybody on the team here has), but people here were hacking on the generator to use it for developing clang & swift not too long ago. The last report I heard was that it still needs more work to be usable, and that that work was not entirely trivial. Without the index, Xcode is a pretty weak IDE, which is why we maintain a hand-built Xcode project. Jim ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Parsing Line Table to determine function prologue?
> > Even if we do need to parse the line table, could it be done just for the > function in question? The debug info tells us the function's address > range, so is there some technical reason why it couldn't parse the line > table only for the given address range? > My understanding is that there's one DWARF .debug_line "program" per CU, and normally you'd need to "execute" the whole line number program. On Sat, Oct 6, 2018 at 8:05 PM, Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > While implementing native PDB support I noticed that LLDB is asking to > parse an entire compile unit's line table in order to determine if 1 > address is a function prologue or epilogue. > > Is this necessary in DWARF-land? It would be nice if I could just pass > the prologue and epilogue byte size directly to the constructor of the > lldb_private::Function object when I construct it. > > It seems unnecessary to parse the entire line table just to set a > breakpoint by function name, but this is what ends up happening. > > Even if we do need to parse the line table, could it be done just for the > function in question? The debug info tells us the function's address > range, so is there some technical reason why it couldn't parse the line > table only for the given address range? > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio?
I build with the VS project. I find it more convenient to do that than have VS and a cmd window open to run ninja. Especially when I’ve got more than 1 copy of VS open looking at different release trains. I wouldn’t mind using ninja to build, but only if it worked when I right click on lldb and select “Build”. Our buildbots use msbuild on the project, like this: call "c:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/vcvarsall.bat" x64 & msbuild ALL_BUILD.vcxproj /m /property:Configuration=Release -- Ted Woodward Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From: lldb-dev On Behalf Of Zachary Turner via lldb-dev Sent: Monday, October 8, 2018 1:58 PM To: Stephen Kelly Cc: llvm-...@lists.llvm.org; cfe-...@lists.llvm.org; lldb-dev@lists.llvm.org Subject: Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio? On Mon, Oct 8, 2018 at 11:54 AM Stephen Kelly via cfe-dev mailto:cfe-...@lists.llvm.org> > wrote: > 3) Even if you do pass -Thost=x64 to CMake, it will apparently still > fail sometimes. See this thread for details: > http://lists.llvm.org/pipermail/cfe-dev/2018-October/059609.html. It > seems the parallel build scheduler does not do a good job and can bring > a machine down. This is not the first time though, every couple of > months there's a thread about how building or running tests from within > VS doesn't work. I don't know any more about this. It would be good to know more than that it can "apparently fail sometimes". Sadly that's part of the problem. Very few people actually use the Visual Studio generator for building, so a lot of times when we get people with issues, nobody knows how to help (or the person that does know doesn't see the thread). So they get a response like "hmm, not many people actually use that workflow, can you try this instead?" I feel bad when I can't help, and that's part of why I made this proposal in the first place, because fewer supported options in the configuration matrix means people are more likely to find someone who understands the problem when something goes wrong. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Parsing Line Table to determine function prologue?
A single sequence in the line table needs to be run from beginning to end to make sense of it. It doesn't really have addresses, it generally has a start address, then a sequence of "increment line, increment address" instructions. So you have to run the state machine to figure out what the addresses are. However, the line table does not have to be one continuous sequence. The DWARF docs state this explicitly, and there is an "end_sequence" instruction to implement this. I can't see any reason why you couldn't get the compiler to emit line tables in per-function sequences, and have the debugger optimize reading the line table by first scanning for sequence ends to get the map of chunks -> addresses, and then reading the line table in those chunks. I don't think anybody does this, however. clang emitted the whole CU as one sequence in the few examples I had sitting around. Jim > On Oct 8, 2018, at 12:28 PM, Leonard Mosescu via lldb-dev > wrote: > > Even if we do need to parse the line table, could it be done just for the > function in question? The debug info tells us the function's address range, > so is there some technical reason why it couldn't parse the line table only > for the given address range? > > My understanding is that there's one DWARF .debug_line "program" per CU, and > normally you'd need to "execute" the whole line number program. > > On Sat, Oct 6, 2018 at 8:05 PM, Zachary Turner via lldb-dev > wrote: > While implementing native PDB support I noticed that LLDB is asking to parse > an entire compile unit's line table in order to determine if 1 address is a > function prologue or epilogue. > > Is this necessary in DWARF-land? It would be nice if I could just pass the > prologue and epilogue byte size directly to the constructor of the > lldb_private::Function object when I construct it. > > It seems unnecessary to parse the entire line table just to set a breakpoint > by function name, but this is what ends up happening. > > Even if we do need to parse the line table, could it be done just for the > function in question? The debug info tells us the function's address range, > so is there some technical reason why it couldn't parse the line table only > for the given address range? > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Parsing Line Table to determine function prologue?
I see. It's not the end of the world because I can just parse the whole line table when requested. It's just that in PDB-land the format is such that a) I know the exact address of the prologue and epilogue at the time I parse the function record, and b) When parsing the line table, I can quickly scan to the address range for the function making the whole table parsing less efficient than necessary. But it's definitely sufficient. On Mon, Oct 8, 2018 at 12:41 PM Jim Ingham wrote: > A single sequence in the line table needs to be run from beginning to end > to make sense of it. It doesn't really have addresses, it generally has a > start address, then a sequence of "increment line, increment address" > instructions. So you have to run the state machine to figure out what the > addresses are. > > However, the line table does not have to be one continuous sequence. The > DWARF docs state this explicitly, and there is an "end_sequence" > instruction to implement this. I can't see any reason why you couldn't get > the compiler to emit line tables in per-function sequences, and have the > debugger optimize reading the line table by first scanning for sequence > ends to get the map of chunks -> addresses, and then reading the line table > in those chunks. I don't think anybody does this, however. clang emitted > the whole CU as one sequence in the few examples I had sitting around. > > Jim > > > > On Oct 8, 2018, at 12:28 PM, Leonard Mosescu via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Even if we do need to parse the line table, could it be done just for > the function in question? The debug info tells us the function's address > range, so is there some technical reason why it couldn't parse the line > table only for the given address range? > > > > My understanding is that there's one DWARF .debug_line "program" per CU, > and normally you'd need to "execute" the whole line number program. > > > > On Sat, Oct 6, 2018 at 8:05 PM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > While implementing native PDB support I noticed that LLDB is asking to > parse an entire compile unit's line table in order to determine if 1 > address is a function prologue or epilogue. > > > > Is this necessary in DWARF-land? It would be nice if I could just pass > the prologue and epilogue byte size directly to the constructor of the > lldb_private::Function object when I construct it. > > > > It seems unnecessary to parse the entire line table just to set a > breakpoint by function name, but this is what ends up happening. > > > > Even if we do need to parse the line table, could it be done just for > the function in question? The debug info tells us the function's address > range, so is there some technical reason why it couldn't parse the line > table only for the given address range? > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] Should we stop supporting building with Visual Studio?
On Mon, Oct 8, 2018 at 12:29 PM wrote: > I build with the VS project. I find it more convenient to do that than > have VS and a cmd window open to run ninja. Especially when I’ve got more > than 1 copy of VS open looking at different release trains. I wouldn’t mind > using ninja to build, but only if it worked when I right click on lldb and > select “Build”. > This seems like a bit of an extreme position to take. We shouldn't be making decisions about supported configurations based on what keyboard / mouse incantation is used to invoke a command. The important thing is whether or not there's a reasonable substitute for peoples' existing workflows. Pushing (for example) Ctrl+Alt+B instead of Ctrl+Shift+B I consider reasonable (or typing ninja from a command prompt I also consider reasonable). ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] SIGPIPE handling
I've had requests from several users now to change the default SIGPIPE handling to "stop = false, notify = false". The argument is that most of the time these signals are generally ignored and folks directly handle the read and write errors. So having lldb stop by default for SIGPIPE is just annoying. And if SIGPIPE debugging is interesting for some project, it is easy to turn this back on. I just copied the gdb defaults as they were 10 years or so ago, there wasn't a better motivation for the way it is in lldb now. The change is easy, but I wanted to make sure nobody has a counter-argument for keeping the current default - which is stop = yes, notify = yes, suppress = no. I'm proposing to change that to stop = no, notify = no, suppress = no. Jim ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
