I’m working on addressing issues that are preventing lldb from compiling on 32-bit arm platforms. Many warnings are generated by the definition of LLDB_INVALID_ADDRESS as UINT64_MAX. Ultimately, it stems from the fact that size_t is 32 bits, which changes it to the value to UINT32_MAX (4294967295). Is it appropriate to define LLDB_INVALID_ADDRESS to be UINT32_MAX on 32-bit platforms and UINT64_MAX on 64-bit platforms, or should I change the references to size_t to an explicitly 64-bit type (such as uint64_t) on all platforms?
On Thu, Dec 24, 2015 at 3:03 PM, William Dillon via swift-dev <swift-dev@swift.org> wrote:
Hi all,
I’m working on addressing issues that are preventing lldb from compiling on 32-bit arm platforms. Many warnings are generated by the definition of LLDB_INVALID_ADDRESS as UINT64_MAX. Ultimately, it stems from the fact that size_t is 32 bits, which changes it to the value to UINT32_MAX (4294967295). Is it appropriate to define LLDB_INVALID_ADDRESS to be UINT32_MAX on 32-bit platforms and UINT64_MAX on 64-bit platforms, or should I change the references to size_t to an explicitly 64-bit type (such as uint64_t) on all platforms?
> Hi all,
>
> I’m working on addressing issues that are preventing lldb from compiling
on 32-bit arm platforms. Many warnings are generated by the definition of
LLDB_INVALID_ADDRESS as UINT64_MAX. Ultimately, it stems from the fact
that size_t is 32 bits, which changes it to the value to UINT32_MAX
(4294967295). Is it appropriate to define LLDB_INVALID_ADDRESS to be
UINT32_MAX on 32-bit platforms and UINT64_MAX on 64-bit platforms, or
should I change the references to size_t to an explicitly 64-bit type (such
as uint64_t) on all platforms?
LLDB supports 32-bit versions debugging 64-bit hosts and vice versa, so we
need LLDB_INVALID_ADDRESS to remain the largest address-sized host we can
communicate with. So LLDB_INVALID_ADDRESS needs to remain 64-bit
everywhere.
It looks like some progress was made on this already as I see we had a
swift-lldb pull request on this.
Thanks for looking into this!
-Todd
···
On Thu, Dec 24, 2015 at 3:15 PM, Dmitri Gribenko via swift-lldb-dev < swift-lldb-dev@swift.org> wrote:
On Thu, Dec 24, 2015 at 3:03 PM, William Dillon via swift-dev > <swift-dev@swift.org> wrote:
Yes, I think that LLDB is more or less working with Swift on ARM. We can start the REPL and do some tasks with it, though it isn’t all that reliable yet. There are two files in the swift-lldb PR that I merged in from Joe Bell that fixed the REPL. I think, however, than they would need to go to the lldb.llvm.org <http://lldb.llvm.org/> repo, rather than the swift one. There is a question about that, though. Joe added armv7l into the ArchSpec table, but I don’t think that armv7l is a real subtype. I’ve been very confused by the ARM nomenclature on linux (I don’t think I’m alone here), and I think that armv7l means armv7 little endian. So, should these get converted to armv7 somewhere else and revert the changes to the ArchSpec table?
Thanks,
- Will
···
On Dec 28, 2015, at 10:10 AM, Todd Fiala <todd.fiala@gmail.com> wrote:
Hi William,
On Thu, Dec 24, 2015 at 3:15 PM, Dmitri Gribenko via swift-lldb-dev <swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>> wrote:
+ swift-lldb-dev
On Thu, Dec 24, 2015 at 3:03 PM, William Dillon via swift-dev > <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
> Hi all,
>
> I’m working on addressing issues that are preventing lldb from compiling on 32-bit arm platforms. Many warnings are generated by the definition of LLDB_INVALID_ADDRESS as UINT64_MAX. Ultimately, it stems from the fact that size_t is 32 bits, which changes it to the value to UINT32_MAX (4294967295). Is it appropriate to define LLDB_INVALID_ADDRESS to be UINT32_MAX on 32-bit platforms and UINT64_MAX on 64-bit platforms, or should I change the references to size_t to an explicitly 64-bit type (such as uint64_t) on all platforms?
LLDB supports 32-bit versions debugging 64-bit hosts and vice versa, so we need LLDB_INVALID_ADDRESS to remain the largest address-sized host we can communicate with. So LLDB_INVALID_ADDRESS needs to remain 64-bit everywhere.
It looks like some progress was made on this already as I see we had a swift-lldb pull request on this.
Yes, I think that LLDB is more or less working with Swift on ARM. We can start the REPL and do some tasks with it, though it isn’t all that reliable yet.
I’d love to hear about the reliability piece if you have more details there!
There are two files in the swift-lldb PR that I merged in from Joe Bell that fixed the REPL. I think, however, than they would need to go to the lldb.llvm.org <http://lldb.llvm.org/> repo, rather than the swift one.
I think I’ve seen the llvm.org <http://llvm.org/> side of that patch. Somebody else and I had a question about some static casts in there, but we’ll catch up on that side if it is the same patch I’m thinking about.
There is a question about that, though. Joe added armv7l into the ArchSpec table, but I don’t think that armv7l is a real subtype. I’ve been very confused by the ARM nomenclature on linux (I don’t think I’m alone here), and I think that armv7l means armv7 little endian. So, should these get converted to armv7 somewhere else and revert the changes to the ArchSpec table?
This is a great question that I am not the right resource to answer. Greg or Jason, any thoughts here on question of arm subtypes? (My first take is that I’d expect each subtype to represent a different set of features and instructions available, and not be used solely for an endianness designation, but that’s not an area I do much work in).
-Todd
···
On Dec 28, 2015, at 10:39 AM, William Dillon via swift-lldb-dev <swift-lldb-dev@swift.org> wrote:
Thanks,
- Will
On Dec 28, 2015, at 10:10 AM, Todd Fiala <todd.fiala@gmail.com <mailto:todd.fiala@gmail.com>> wrote:
Hi William,
On Thu, Dec 24, 2015 at 3:15 PM, Dmitri Gribenko via swift-lldb-dev <swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>> wrote:
+ swift-lldb-dev
On Thu, Dec 24, 2015 at 3:03 PM, William Dillon via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
> Hi all,
>
> I’m working on addressing issues that are preventing lldb from compiling on 32-bit arm platforms. Many warnings are generated by the definition of LLDB_INVALID_ADDRESS as UINT64_MAX. Ultimately, it stems from the fact that size_t is 32 bits, which changes it to the value to UINT32_MAX (4294967295). Is it appropriate to define LLDB_INVALID_ADDRESS to be UINT32_MAX on 32-bit platforms and UINT64_MAX on 64-bit platforms, or should I change the references to size_t to an explicitly 64-bit type (such as uint64_t) on all platforms?
LLDB supports 32-bit versions debugging 64-bit hosts and vice versa, so we need LLDB_INVALID_ADDRESS to remain the largest address-sized host we can communicate with. So LLDB_INVALID_ADDRESS needs to remain 64-bit everywhere.
It looks like some progress was made on this already as I see we had a swift-lldb pull request on this.
We have discussed this before with Tim Northover, and he suggested that we
canonicalize armv7l to armv7 when parsing the triple from the command line.
Dmitri
···
On Mon, Jan 4, 2016 at 6:50 PM, Todd Fiala via swift-lldb-dev < swift-lldb-dev@swift.org> wrote:
On Dec 28, 2015, at 10:39 AM, William Dillon via swift-lldb-dev < > swift-lldb-dev@swift.org> wrote:
Hi Todd,
Yes, I think that LLDB is more or less working with Swift on ARM. We can
start the REPL and do some tasks with it, though it isn’t all that reliable
yet.
I’d love to hear about the reliability piece if you have more details
there!
There are two files in the swift-lldb PR that I merged in from Joe Bell
that fixed the REPL. I think, however, than they would need to go to the
lldb.llvm.org repo, rather than the swift one.
I think I’ve seen the llvm.org side of that patch. Somebody else and I
had a question about some static casts in there, but we’ll catch up on that
side if it is the same patch I’m thinking about.
There is a question about that, though. Joe added armv7l into the
ArchSpec table, but I don’t think that armv7l is a real subtype. I’ve been
very confused by the ARM nomenclature on linux (I don’t think I’m alone
here), and I think that armv7l means armv7 little endian. So, should these
get converted to armv7 somewhere else and revert the changes to the
ArchSpec table?
This is a great question that I am not the right resource to answer. *Greg
or Jason,* any thoughts here on question of arm subtypes? (My first take
is that I’d expect each subtype to represent a different set of features
and instructions available, and not be used solely for an endianness
designation, but that’s not an area I do much work in).
I added some more comments to the pull request that I Think is related to this thread here:
The archspec changes really need to happen in llvm.org <http://llvm.org/> lldb svn trunk and need to be put up for patch review there (along with any discussion particular to that). The rest of the change (for 32-bit support specific to Swift LLDB) looked fine. If we get that separated out again, I’ll be happy to get that in.
Thanks!
-Todd
···
On Jan 4, 2016, at 9:00 AM, Dmitri Gribenko via swift-lldb-dev <swift-lldb-dev@swift.org> wrote:
On Mon, Jan 4, 2016 at 6:50 PM, Todd Fiala via swift-lldb-dev <swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>> wrote:
On Dec 28, 2015, at 10:39 AM, William Dillon via swift-lldb-dev <swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>> wrote:
Hi Todd,
Yes, I think that LLDB is more or less working with Swift on ARM. We can start the REPL and do some tasks with it, though it isn’t all that reliable yet.
I’d love to hear about the reliability piece if you have more details there!
There are two files in the swift-lldb PR that I merged in from Joe Bell that fixed the REPL. I think, however, than they would need to go to the lldb.llvm.org <http://lldb.llvm.org/> repo, rather than the swift one.
I think I’ve seen the llvm.org <http://llvm.org/> side of that patch. Somebody else and I had a question about some static casts in there, but we’ll catch up on that side if it is the same patch I’m thinking about.
There is a question about that, though. Joe added armv7l into the ArchSpec table, but I don’t think that armv7l is a real subtype. I’ve been very confused by the ARM nomenclature on linux (I don’t think I’m alone here), and I think that armv7l means armv7 little endian. So, should these get converted to armv7 somewhere else and revert the changes to the ArchSpec table?
This is a great question that I am not the right resource to answer. Greg or Jason, any thoughts here on question of arm subtypes? (My first take is that I’d expect each subtype to represent a different set of features and instructions available, and not be used solely for an endianness designation, but that’s not an area I do much work in).
We have discussed this before with Tim Northover, and he suggested that we canonicalize armv7l to armv7 when parsing the triple from the command line.
The archspec changes really need to happen in llvm.org <http://llvm.org/> lldb svn trunk and need to be put up for patch review there (along with any discussion particular to that). The rest of the change (for 32-bit support specific to Swift LLDB) looked fine. If we get that separated out again, I’ll be happy to get that in.
That sounds good.
To summarize how changes in these three projects link together:
there is some code in swift that tries to canonicalize armv6l and armv7l into just ‘armv6’ and ‘armv7’ respectively. This was suggested by Dmitri and Tim. However, armv6l isn’t represented in llvm, and I’m working on bringing my patch there up to standards. However, this canonicalization only applies to compilation, not the REPL. Joe Bell figured out that LLDB was being passed armv6l and armv7l and it didn’t know what to do with them. He fixed that by adding them to lldb. The correct approach seems to be performing the same transformation for the REPL as for compilation, and therefore the other proposed changes to LLDB are inappropriate. I’ll back those out as Todd suggested.
I want to do these operations in such a way that Joe always has a set of repos that will build functioning binaries for ARM because he’s been great at releasing updates as other parts of swift for linux mature. To that end, I’ll figure out the changes necessary to swift’s invocation of LLDB and submit a PR for that. Then, I’ll back-out the changes to LLDB. The changes to LLVM can happen any time.
Apologies for any incoherencies, I’ve got a cold at the moment. :)
- Will
···
On Jan 4, 2016, at 9:17 AM, Todd Fiala <tfiala@apple.com> wrote:
On Jan 4, 2016, at 9:00 AM, Dmitri Gribenko via swift-lldb-dev <swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>> wrote:
On Mon, Jan 4, 2016 at 6:50 PM, Todd Fiala via swift-lldb-dev <swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>> wrote:
On Dec 28, 2015, at 10:39 AM, William Dillon via swift-lldb-dev <swift-lldb-dev@swift.org <mailto:swift-lldb-dev@swift.org>> wrote:
Hi Todd,
Yes, I think that LLDB is more or less working with Swift on ARM. We can start the REPL and do some tasks with it, though it isn’t all that reliable yet.
I’d love to hear about the reliability piece if you have more details there!
There are two files in the swift-lldb PR that I merged in from Joe Bell that fixed the REPL. I think, however, than they would need to go to the lldb.llvm.org <http://lldb.llvm.org/> repo, rather than the swift one.
I think I’ve seen the llvm.org <http://llvm.org/> side of that patch. Somebody else and I had a question about some static casts in there, but we’ll catch up on that side if it is the same patch I’m thinking about.
There is a question about that, though. Joe added armv7l into the ArchSpec table, but I don’t think that armv7l is a real subtype. I’ve been very confused by the ARM nomenclature on linux (I don’t think I’m alone here), and I think that armv7l means armv7 little endian. So, should these get converted to armv7 somewhere else and revert the changes to the ArchSpec table?
This is a great question that I am not the right resource to answer. Greg or Jason, any thoughts here on question of arm subtypes? (My first take is that I’d expect each subtype to represent a different set of features and instructions available, and not be used solely for an endianness designation, but that’s not an area I do much work in).
We have discussed this before with Tim Northover, and he suggested that we canonicalize armv7l to armv7 when parsing the triple from the command line.
The archspec changes really need to happen in llvm.org lldb svn trunk and
need to be put up for patch review there (along with any discussion
particular to that). The rest of the change (for 32-bit support specific
to Swift LLDB) looked fine. If we get that separated out again, I’ll be
happy to get that in.
That sounds good.
To summarize how changes in these three projects link together:
there is some code in swift that tries to canonicalize armv6l and armv7l
into just ‘armv6’ and ‘armv7’ respectively. This was suggested by Dmitri
and Tim. However, armv6l isn’t represented in llvm, and I’m working on
bringing my patch there up to standards. However, this canonicalization
only applies to compilation, not the REPL. Joe Bell figured out that LLDB
was being passed armv6l and armv7l and it didn’t know what to do with
them. He fixed that by adding them to lldb. The correct approach seems to
be performing the same transformation for the REPL as for compilation, and
therefore the other proposed changes to LLDB are inappropriate. I’ll back
those out as Todd suggested.
Sounds good.
I want to do these operations in such a way that Joe always has a set of
repos that will build functioning binaries for ARM because he’s been great
at releasing updates as other parts of swift for linux mature. To that
end, I’ll figure out the changes necessary to swift’s invocation of LLDB
and submit a PR for that. Then, I’ll back-out the changes to LLDB. The
changes to LLVM can happen any time.
Okay.
Apologies for any incoherencies, I’ve got a cold at the moment. :)
I hope you feel better! Totally coherent fwiw :-)
-Todd
···
On Mon, Jan 4, 2016 at 9:45 AM, William Dillon via swift-lldb-dev < swift-lldb-dev@swift.org> wrote:
On Jan 4, 2016, at 9:17 AM, Todd Fiala <tfiala@apple.com> wrote:
- Will
On Jan 4, 2016, at 9:00 AM, Dmitri Gribenko via swift-lldb-dev < > swift-lldb-dev@swift.org> wrote:
On Mon, Jan 4, 2016 at 6:50 PM, Todd Fiala via swift-lldb-dev < > swift-lldb-dev@swift.org> wrote:
On Dec 28, 2015, at 10:39 AM, William Dillon via swift-lldb-dev < >> swift-lldb-dev@swift.org> wrote:
Hi Todd,
Yes, I think that LLDB is more or less working with Swift on ARM. We can
start the REPL and do some tasks with it, though it isn’t all that reliable
yet.
I’d love to hear about the reliability piece if you have more details
there!
There are two files in the swift-lldb PR that I merged in from Joe Bell
that fixed the REPL. I think, however, than they would need to go to the
lldb.llvm.org repo, rather than the swift one.
I think I’ve seen the llvm.org side of that patch. Somebody else and I
had a question about some static casts in there, but we’ll catch up on that
side if it is the same patch I’m thinking about.
There is a question about that, though. Joe added armv7l into the
ArchSpec table, but I don’t think that armv7l is a real subtype. I’ve been
very confused by the ARM nomenclature on linux (I don’t think I’m alone
here), and I think that armv7l means armv7 little endian. So, should these
get converted to armv7 somewhere else and revert the changes to the
ArchSpec table?
This is a great question that I am not the right resource to answer. *Greg
or Jason,* any thoughts here on question of arm subtypes? (My first
take is that I’d expect each subtype to represent a different set of
features and instructions available, and not be used solely for an
endianness designation, but that’s not an area I do much work in).
We have discussed this before with Tim Northover, and he suggested that we
canonicalize armv7l to armv7 when parsing the triple from the command line.