Oh sorry I missed that. Yes, I think a value added to the OSType for NoOS or
something would work. We need to standardize on a textual representation for
this in a triple string as well, like 'none'. Then with arm64-- and arm64-*-*
as UnknownVendor + UnknownOS we can have these marked as
That's what I mean though, perhaps we could add a value to the OSType
enumeration like BareMetal or None to explicitly represent this. the
SubArchType enum has NoSubArch, so it's not without precedent. As long as
you can express it in the triple format, the problem goes away.
On Thu, Dec 6,
There is genuinely no OS in some cases, like people who debug the software that
runs in a keyboard or a mouse. And to higher-level coprocessors in a modern
phones; the SOCs on all these devices have a cluster of processors, and only
some of them are running an identifiable operating system,
Is there some reason we can’t define vendors, environments, arches, and
oses for all supported use cases? That way “there is no os” would not ever
be a thing.
On Thu, Dec 6, 2018 at 3:37 PM Jason Molenda via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I think the confusing thing is when
I agree with Davide. Particularly if there’s code that is relying on the
“IsExactMatch” not behaving like the function name makes clear it obviously
should behave, we should straighten that out. Otherwise reasoning about this
will be too confusing.
Jim
> On Dec 6, 2018, at 3:26 PM, Davide
I think the confusing thing is when "unspecified" means "there is no OS" or
"there is no vendor" versus "vendor/OS is unspecified".
Imagine debugging a firmware environment where we have a cpu arch, and we may
have a vendor, but we specifically do not have an OS. Say armv7-apple-none (I
make
On Thu, Dec 6, 2018 at 3:20 PM Adrian Prantl via lldb-dev
wrote:
>
> I was puzzled by the behavior of ArchSpec::IsExactMatch() and
> IsCompatibleMatch() yesterday, so I created a couple of unit tests to
> document the current behavior. Most of the tests make perfect sense, but a
> few edge
I was puzzled by the behavior of ArchSpec::IsExactMatch() and
IsCompatibleMatch() yesterday, so I created a couple of unit tests to document
the current behavior. Most of the tests make perfect sense, but a few edge
cases really don't behave like I would have expected them to.
> {
>
On Thu, Dec 6, 2018 at 6:39 AM Gábor Márton wrote:
>
> Hi Davide,
>
> Thank you for your email.
>
> > In particular, what's the error you get when lldb fails immediately running
> > the tests?
> > Also, have you checked libcxx and libcxx-abi in your build? We might
> > consider making that a
I like this a lot!
I commented on the patch since I didn't see this thread at the time, but
it'd be interesting to perhaps replace Epydoc with Sphinx as well.
- Bruce
On Fri, Dec 7, 2018 at 12:02 AM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Hi everyone,
>
> The
Hi everyone,
The current LLDB website is written in HTML which is hard to maintain. We have
quite a bit of HTML code checked in which can make it hard to differentiate
between documentation written by us and documentation generated by a tool.
Furthermore I think text/RST files provide a lower
Hi Davide,
Thank you for your email.
> In particular, what's the error you get when lldb fails immediately
running the tests?
> Also, have you checked libcxx and libcxx-abi in your build? We might
> consider making that a mandatory dependency for the Cmake build.
Finally I could run the test
12 matches
Mail list logo
