[Lldb-commits] [PATCH] D52618: [Windows] A basic implementation of memory allocations in a debuggee process

[Zachary Turner via Phabricator via lldb-commits]

zturner added a comment.

In https://reviews.llvm.org/D52618#1252372, @labath wrote:

> In https://reviews.llvm.org/D52618#1250909, @zturner wrote:
>
> > One idea would be to define some lit substitutions like %debuginfo. It’s
> >  true you can produce a gcc style command line that will be equivalent to a
> >  clang-cl invocation but it won’t be easy. eg you’ll needing to pass
> >  -fms-compatibility as well as various -I for includes.
> >
> > It may be easier to have substitutions instead
>
>
> Using substitutions SGTM.
>
> I am not sure if this is a good idea, but it had occured to me that we could put `-fms-compatibility` and friends into a substitution of it's own, which would be computed by lit (through some equivalent of `clang++ -###` ?). That way, the tests could still use g++ syntax, only the command lines would contain an extra `%cflags` argument. This has the advantage of extra flexibility over a predefined set of compile commands (%compile_with_debug, %compile_without_debug, ...), and it might be sufficient to make cross-compiling work, if we ever need it.


Another idea I just thought of, which would basically be the heaviest hammer possible and give the most flexibility is to modify the lit infrastructure (just for lldb, not all of llvm) to look for a `compiler_config.py` file.  If it finds it, it can run the file.  This file could define whatever substitutions it wanted.  In the top-level LLDB lit configuration, we could provide some basic common infrastructure to easily support common use cases.  I don't have specifics in mind for how the implementation would look like, but from a user point of view (i.e. what the `compiler_config.py` would look like), I'm imagining you could write something like this:

  # compiler_config.py
  global compiler_config
  compiler_config.create_configuration(
      "fooconfig",   # user can reference this config as 'fooconfig' from a test file.
      driver=best,    # use clang-cl on Windows, clang++ otherwise
      debug=True,   # pass /Z7 on Windows, -g otherwise
      optlevel=1,     # pass /O2 on Windows, -O2 otherwise
      output_type=sharedlib,   # pass -fPIC on Linux and /D_DLL on Windows
      exceptions=False,     # pass -fno-exceptions on Linux, /EHs-c- on Windows
      rtti=False,   # pass -fno-rtti on Linux, /GR- on Windows
      mode=compile-only)   # Don't run the linker
  
  compiler_config.create_configuration(
      "barconfig", # user can reference this config as 'barconfig' from a test file.
      driver=g++, # this config always invokes clang++, never anything else.
      debug=False, optlevel=3, output_type=exe)  # etc

Then, in your test file, you could have:

  ; RUN: %fooconfig %p/foo.cpp
  ; RUN: %barconfig %p/bar.cpp

This is a very rough outline of the idea, but I think this could actually be really cool if done properly.


https://reviews.llvm.org/D52618