[Lldb-commits] [PATCH] Properly decode architecture type in GDBRemoteCommunicationClient::GetCurrentProcessInfo.

[Todd Fiala]

If that's the case then it is a non-issue.

I'll have to go back through the list to see where Greg and I were talking
about that.  I might be mis-remembering the context on why we moved away
from cputype/cpusubtype and towards triple on non-Apple platforms.

-Todd

On Mon, Sep 15, 2014 at 9:46 AM, Stephane Sezer <sas at fb.com> wrote:

> Mhmm, as far as I can tell, these constants are not all controlled by
> Apple. For instance, for ELF arch_type, the table g_elf_arch_entries in
> ArchSpec.cpp contains values pulled directly from the ELF spec (EM_ARM,
> EM_X86_64 for instance).
>
> On Sep 15, 2014, at 8:46 AM, Todd Fiala <tfiala at google.com> wrote:
>
> > I'm going to check this out now.
> >
> > Regarding cputype/cpusubtype, I think the challenge we'll run on
> non-Apple platforms is that I think those constants are all controlled by
> Apple (i.e. authoritative source).  What happens when a gdb-remote stub is
> sending cputype/cpusubtype and using a non-Apple-supported cpu
> architecture, which surely is a possibility at some point?  I think to
> avoid that scenario, it's best to avoid Apple-specific cputype/cpusubtype
> info on non-Apple gdb-remote stubs.
> >
> > (Apple guys - correct me if I'm wrong here).
> >
> > Testing the change now.
> >
> > -Todd
> >
> > On Wed, Sep 10, 2014 at 1:50 PM, Todd Fiala <tfiala at google.com> wrote:
> > I'm not averse to the change.  But I stumbled across a few places in the
> code where, once we see cputype/cpuinfo, we start assuming we are in Apple
> code.  And to keep everyone sane, if you can migrate to using triples on
> non-Apple hardware, I think that's a good idea.
> >
> > Probably good if there's a once over on the change from an Apple team
> member on this here.
> >
> > On Wed, Sep 10, 2014 at 1:43 PM, Stephane Sezer <sas at fb.com> wrote:
> > Hey Todd,
> >
> > Yes, you are correct. I needed this patch for non-Apple targets that
> send a cputype/cpusubtype couple instead of a full triple. If this is
> something that you guys think is invalid, I can deal with it on the debug
> server we are using.
> >
> > AFAICT, right now we have two ways of getting the process info: one with
> the triples, which works everywhere, and one with cputype/cpusubtype that
> works only with apple targets. This would make both ways work everywhere in
> theory.
> >
> > On Sep 10, 2014, at 10:36 AM, Todd Fiala <tfiala at google.com> wrote:
> >
> > > Hey Stephane!
> > >
> > > On this patch, one of the things I'm seeing is that it appears you are
> (maybe?) sending cputype and cpusubtype in cases where the target is not a
> MachO-based system.  In general, the cputype/cpusubtype are meant to be a
> MachO-xnu specific mechanism.  We try to *not* send those for non-Apple
> targets and instead send just the triples.
> > >
> > > Are you in a position where this might be the case?  I can try out the
> patch but it looks like it's basically geared to handle qProcessInfo for
> non-MachO platforms sending cpu type info if I'm reading it right.
> > >
> > > -Todd
> > >
> > > On Tue, Sep 9, 2014 at 5:23 PM, Stephane Sezer <sas at fb.com> wrote:
> > > Instead of forcing the remote arch type to MachO all the time, we
> > > inspect the OS/vendor that the remote debug server reports and use it
> to
> > > set the arch type to MachO, ELF or COFF accordingly.
> > >
> > >
> > > _______________________________________________
> > > lldb-commits mailing list
> > > lldb-commits at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> > >
> > >
> > >
> > >
> > > --
> > > Todd Fiala |   Software Engineer |     tfiala at google.com |
> 650-943-3180
> > >
> >
> >
> >
> >
> > --
> > Todd Fiala |   Software Engineer |     tfiala at google.com |
> 650-943-3180
> >
> >
> >
> >
> > --
> > Todd Fiala |   Software Engineer |     tfiala at google.com |
> 650-943-3180
> >
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140915/a38a8762/attachment.html>