[lldb-dev] [Bug 35860] New: displaying some long double values causes lldb to crash

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=35860

Bug ID: 35860
   Summary: displaying some long double values causes lldb to
crash
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: oli...@apple.com
CC: llvm-b...@lists.llvm.org

If I have something along the lines of:

  union {
struct {
  int x;
  int y;
  int node_index;
} as_point;
long double as_number;
  } data;
  data.as_point.x = 0;
  data.as_point.y = 0;
  data.as_point.node_index = 512;

and pause after assigning to node_index, then try to display the struct:

p data

lldb crashes. I've reduced this to the problem being the display of the long
double, specifically it seems to be going wrong when the mantissa is zero but
the exponent in non-zero. Given the wonkiness of long double on x86 I assume
this is incorrect handling of a denormal (pseudo-denormal? I was reading some
of the docs on it and that appears to be a thing #wat).

It's a real problem in Xcode as Xcode auto displays the values of all locals
and so lldb crashes whenever this happens. I can work around this if I know it
may happen in a given function by manually setting the display type to
hex/binary/anything-other-than-default.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 35857] New: Deprecate/remove the lldb private regex implementation

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=35857

Bug ID: 35857
   Summary: Deprecate/remove the lldb private regex implementation
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Keywords: beginner
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: dav...@freebsd.org
CC: apra...@apple.com, jing...@apple.com,
llvm-b...@lists.llvm.org

Utility/RegularExpression in LLDB has a regex engine which can be replaced by
the code in llvm/Support/Regex.h
This would remove a bunch of duplicated code and as added bonus will improve
coverage (as the regex code in LLVM is largely unit tested). There might be
some missing features that can be implemented, haven't looked closely.

Marking as `beginner` bug, while I'm here.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to handle "O XX..." reply packets from gdb servers like openocd

[Greg Clayton via lldb-dev]

Then the right way to fix this is to somehow allow the rCmd to watch for the 
"O" packets in its responses. Since no other commands want this and the send 
continue packets use a special send packet and receive response, we might must 
want a SendPacketAndReceiveResponseWithOutputSupport(...) that rCmd will use. 
We could also add a bool to the stand send packet and receive response that 
indicates if "O" packet responses are possible, my only objection to that is it 
makes it seem like any command can just opt into getting "O" responses. If rCmd 
is the only other packet other than continue, I would do add the 
SendPacketAndReceiveResponseWithOutputSupport  and call it explicitly from the 
rCmd handler. I am open to other suggestions. 

Greg

> On Jan 4, 2018, at 9:14 AM, Pedro Alves  wrote:
> 
> On 01/03/2018 07:11 PM, Greg Clayton via lldb-dev wrote:
>> 
>>> On Jan 1, 2018, at 6:30 PM, Owen Shaw via lldb-dev 
>>>  wrote:
>>> 
>>> I dug into this a bit more, and these output reply packets seem to be
>>> handled already, but only if the program is running.
>> 
>>> Since the relevant openocd commands are often issued when the program
>>> paused, the reply packets aren't processed as expected.
>>> 
>>> The spec does say that reply packets can happen "any time while the
>>> program is running", so perhaps openocd is abusing the protocol, but
>>> gdb handles the packets just fine when stopped.
>> 
>> Yes, LLDB is assuming that an "O" packet will only come during a continue 
>> command. "O" is for stdout output and it seems the rCmd assuming it will 
>> work. Why not just send back the text in response to the rCmd? Is some 
>> common code path being hit where it might send this text while running and 
>> also in response to the rCmd? I am confused by "O" packets are needed in 
>> response to the rCmd.
> 
> qRcmd was invented well before my time, but qRcmd provides support
> for running random interpreter commands on the server, with the
> resulting output being potentially long, unbounded.  Thus sending the
> text back in response to qRcmd would require an unbounded packet buffer
> and would potentially hit the max packet size.  So you'd need some
> way to send partial output in chunks.  Which ends up being exactly what
> you get by reusing "O".
> 
>> If the rCmd can't be fixed to just return the text without using "O" 
>> packets, 
> 
> The documentation of the qRcmd packet explicitly specifies that output
> should be sent via "O" packets:
> 
> https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#index-qRcmd-packet
>  
> 
> 
> Sounds like OpenOCD is working as intended.
> 
> Pedro Alves

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM Social - Paris: January 30th, 2018

[Arnaud Allard de Grandmaison via lldb-dev]

The next LLVM social in Paris will happen on January 30th, 2018.

Everyone interested in LLVM, Clang, lldb, Polly, lld, ... is invited to
join.

Event details, including registration (free but mandatory) at
http://www.meetup.com/LLVM-Clang-social

For this meetup, Adrien Guinet, Serge Guelton and Juan Manuel Martinez will
talk about the "Challenges when building an LLVM bitcode obfuscator", based
on their 4 years experience building an industrial strength code obfuscator
for C/C++ and Objective C.

Looking forward to meet you !
-- Arnaud de Grandmaison, Duncan Sands, Sylvestre Ledru
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev