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 <tfi...@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 <tfi...@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 <s...@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 <tfi...@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 <s...@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@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
> >
> >
> >
> >
> > --
> > Todd Fiala |   Software Engineer |     tfi...@google.com |     650-943-3180
> >
> 
> 
> 
> 
> -- 
> Todd Fiala |   Software Engineer |     tfi...@google.com |     650-943-3180
> 
> 
> 
> 
> -- 
> Todd Fiala |   Software Engineer |     tfi...@google.com |     650-943-3180
> 


_______________________________________________
lldb-commits mailing list
lldb-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits

Reply via email to