[Lldb-commits] [PATCH] D79491: [lldb] Revive TestBasicEntryValuesX86_64

[Pavel Labath via Phabricator via lldb-commits]

labath marked an inline comment as done.
labath added a comment.

In D79491#2024849 <https://reviews.llvm.org/D79491#2024849>, @djtodoro wrote:

> I see.. Enabling it only for specific OSes  could be a temp solution, but we can discuss about that.
>
> > A different way to address this would be to remove the requirement for a running process. The test doesn't really require that, it just needs a relatively complex static snapshot of the process. A core file is just that, but we currently don't have any good way of creating such core files. If we had that, we could run this test over a core file. That would still be platform specific, but then it wouldn't matter (so much) because it wouldn't be tied to the host platform.
>
> Good idea! A corefile could be solution, and I believe LLDB parses corefiles from other architectures very well (as multiarch GDB does).


Yes, the trick there will be to figure out a core file representation that is both readable and expressive enough to work for this as well as various other use cases (I think this approach would be very useful for testing general unwinding machinery).



================
Comment at: lldb/test/API/functionalities/param_entry_vals/basic_entry_values/TestBasicEntryValues.py:5
+
+supported_archs = ["x86_64", "arm", "aarch64"]
+
----------------
djtodoro wrote:
> labath wrote:
> > djtodoro wrote:
> > > I haven't refreshed the page before submitting my previous comment.
> > > 
> > > WDYT about adding a decorators-function (e.g. `skipUnlessEntryValuesSupportedArch`) so we can use it in other tests as well?
> > I think that's a good idea, and that the check can be folded into the existing `skipUnlessHasCallSiteInfo` decorator.
> Please note that entry values and call site info are not the same thing. Entry values implementation ended up describing target-specific instructions (in terms of DWARF operations) that loads values into registers that transfers the parameters, and that is used for the entry values printing. Eventually, we will have all targets supporting the entry values, but the call site Info is something different. The call site info is controlled by the `DIFlagAllCallsDescribed` flag, and it is generated by the language front-end, according to DWARF standard. Therefore, it makes sense to me to add new independent function (`skipUnlessEntryValuesSupportedArch`), but the whole feature depends on both `skipUnlessEntryValuesSupportedArch` and `skipUnlessHasCallSiteInfo`.
Ah, right. Yes, that makes sense. I'll create a separate patch for the new decorator.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79491/new/

https://reviews.llvm.org/D79491