Re: [Lldb-commits] [PATCH] Properly decode architecture type in GDBRemoteCommunicationClient::GetCurrentProcessInfo.
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 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 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 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 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 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 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 > > > > -- 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
Re: [Lldb-commits] [PATCH] Properly decode architecture type in GDBRemoteCommunicationClient::GetCurrentProcessInfo.
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 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 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 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 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 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
Re: [Lldb-commits] [PATCH] Properly decode architecture type in GDBRemoteCommunicationClient::GetCurrentProcessInfo.
Submitted here: svn commit Sending source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp Transmitting file data . Committed revision 217779. On Mon, Sep 15, 2014 at 8:46 AM, Todd Fiala 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 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 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 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 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 > -- 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
Re: [Lldb-commits] [PATCH] Properly decode architecture type in GDBRemoteCommunicationClient::GetCurrentProcessInfo.
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 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 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 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 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
Re: [Lldb-commits] [PATCH] Properly decode architecture type in GDBRemoteCommunicationClient::GetCurrentProcessInfo.
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 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 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 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 ___ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] Properly decode architecture type in GDBRemoteCommunicationClient::GetCurrentProcessInfo.
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 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 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 > ___ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] Properly decode architecture type in GDBRemoteCommunicationClient::GetCurrentProcessInfo.
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 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 ___ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] Properly decode architecture type in GDBRemoteCommunicationClient::GetCurrentProcessInfo.
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. 0001-Properly-decode-architecture-type-in-GDBRemoteCommun.patch Description: 0001-Properly-decode-architecture-type-in-GDBRemoteCommun.patch ___ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
