[swift-dev] [swift-lldb-dev] LLDB Invalid address (32 bit arm)

[Todd Fiala]

> On Dec 28, 2015, at 10:39 AM, William Dillon via swift-lldb-dev <swift-lldb-dev at 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).

-Todd

> 
> Thanks,
> - Will 
> 
>> On Dec 28, 2015, at 10:10 AM, Todd Fiala <todd.fiala at gmail.com <mailto:todd.fiala at gmail.com>> wrote:
>> 
>> Hi William,
>> 
>> On Thu, Dec 24, 2015 at 3:15 PM, Dmitri Gribenko via swift-lldb-dev <swift-lldb-dev at swift.org <mailto:swift-lldb-dev at swift.org>> wrote:
>> + swift-lldb-dev
>> 
>> On Thu, Dec 24, 2015 at 3:03 PM, William Dillon via swift-dev
>> <swift-dev at swift.org <mailto:swift-dev at 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.
>> 
>> Thanks for looking into this!
>> 
>> -Todd
>>  
>> >
>> > Thanks!
>> > - Will
>> > _______________________________________________
>> > swift-dev mailing list
>> > swift-dev at swift.org <mailto:swift-dev at swift.org>
>> > https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>> 
>> 
>> 
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com <mailto:gribozavr at gmail.com>>*/
>> _______________________________________________
>> swift-lldb-dev mailing list
>> swift-lldb-dev at swift.org <mailto:swift-lldb-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-lldb-dev <https://lists.swift.org/mailman/listinfo/swift-lldb-dev>
>> 
>> 
>> 
>> -- 
>> -Todd
> 
>  _______________________________________________
> swift-lldb-dev mailing list
> swift-lldb-dev at swift.org <mailto:swift-lldb-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-lldb-dev <https://lists.swift.org/mailman/listinfo/swift-lldb-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160104/de69da3a/attachment.html>