If you can get that in, that would be great!
Jim
> On Apr 6, 2017, at 10:27 AM, Zachary Turner <ztur...@google.com> wrote:
>
> Honestly i think it seems reasonable for getAsInteger to just work in this
> case, so I'll try to add it to llvm
> On Thu, Apr 6, 2017 at 10:15 AM Jim Ingham <jing...@apple.com> wrote:
> BTW, Jason says that sometimes the gdb remote protocol does send 0x prefaced
> numbers. Apparently not in the cases which have been changed to use
> getAsInteger with a radix of 16, but that is something we'll have to keep in
> mind.
>
> Jim
>
> > On Apr 5, 2017, at 6:55 PM, Jim Ingham <jing...@apple.com> wrote:
> >
> > base of 16 was only used in a few places. It's used frequently in the gdb
> > remote protocol code, but I don't think the gdb remote protocol ever sends
> > hex numbers with the 0x prefix, it assumes you know the radix, so that
> > should be okay. Other than that this was the only consequential usage. So
> > I went with detecting the 0x by hand and treating that separately (r299609).
> >
> > Why does getAsInteger return false if it succeeds in getting an integer?
> > That just seems weird to me.
> >
> > Jim
> >
> >
> >> On Apr 5, 2017, at 4:36 PM, Jim Ingham via lldb-dev
> >> <lldb-dev@lists.llvm.org> wrote:
> >>
> >> It does seem unfortunate that getAsInteger works differently from strtol's
> >> documented behavior in this little way... Makes conversions like this one
> >> trickier than necessary. But presumably somebody had a reason for it to
> >> be different?
> >>
> >> Anyway, I have to go see if this feature of strtol & Co. is used in more
> >> places than CommandObjectMemoryWrite. If it was a common idiom then it
> >> might be nice to have direct support for it. But if it's just in one
> >> place, then hacking around it like this seems fine.
> >>
> >> Jim
> >>
> >>> On Apr 5, 2017, at 4:18 PM, Zachary Turner <ztur...@google.com> wrote:
> >>>
> >>> What if you write this:
> >>>
> >>> // Explicitly try hex. This will catch the case where there is no 0x
> >>> prefix.
> >>> if (entry.ref.getAsInteger(16, uval64)) {
> >>> // If that fails, let the algorithm auto-detect the radix. This will
> >>> catch the case where there is a 0x prefix.
> >>> if (entry.ref.getAsInteger(0, uval64)) {
> >>>
> >>> Would that work? Alternatively, we could probably update the
> >>> implementation of getAsInteger in LLVM to you to manually hint the radix
> >>> AND prefix the number, as long as the prefix matches the hint.
> >>>
> >>> On Wed, Apr 5, 2017 at 4:10 PM Jim Ingham <jing...@apple.com> wrote:
> >>>>
> >>>
> >>> I think somebody was being too clever. The real purpose for specifying
> >>> the format is to set the byte size of the item written down:
> >>>
> >>> OptionValueUInt64 &byte_size_value =
> >>> m_format_options.GetByteSizeValue();
> >>> size_t item_byte_size = byte_size_value.GetCurrentValue();
> >>>
> >>> and to do some special magic for c-strings and the like. Somebody (not
> >>> me) must have thought overloading "hex" format to mean "you can drop the
> >>> 0x" was a tasty little side benefit.
> >>>
> >>> But it's been that way forever, and I don't know who's relying on that
> >>> behavior, so I'd rather not change it (intentionally) if we don't have to.
> >>>
> >>> Jim
> >>>
> >>>> On Wed, Apr 5, 2017 at 3:37 PM Jim Ingham via lldb-dev
> >>>> <lldb-dev@lists.llvm.org> wrote:
> >>>> memory write's argument ingestion was changed as part of the
> >>>> StringRefifying of Args so that we get:
> >>>>
> >>>> (lldb) memory write &buffer 0x62
> >>>> error: '0x62' is not a valid hex string value.
> >>>>
> >>>> That seems unexpected and not desirable. What's going on is that the
> >>>> default format is hex, and if the format is hex, the command also
> >>>> supports:
> >>>>
> >>>> (lldb) memory write -f x &buffer 62
> >>>> (lldb) fr v/x buffer[0]
> >>>> (char) buffer[0] = 0x62
> >>>>
> >>>> The StringRef version of the args parsing is:
> >>>>
> >>>> case eFormatDefault:
> >>>> case eFormatBytes:
> >>>> case eFormatHex:
> >>>> case eFormatHexUppercase:
> >>>> case eFormatPointer:
> >>>> // Decode hex bytes
> >>>> if (entry.ref.getAsInteger(16, uval64)) {
> >>>>
> >>>> The problem is that passing "0x62" to getAsInteger with a radix of 16
> >>>> rejects "0x62".
> >>>>
> >>>> We do want to hint the radix. But it seems weird to reject an explicit
> >>>> indicator. Is there some clever way to use the StringRef functions to
> >>>> get the desired effect, or do I have to hack around this by manually
> >>>> stripping the 0x if I see it?
> >>>>
> >>>> Jim
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> lldb-dev mailing list
> >>>> lldb-dev@lists.llvm.org
> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>>
> >>
> >> _______________________________________________
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
