[lldb-dev] [Bug 40112] LLDB crashes (SEGV) by pressing ↑ in the first entry in print

[via lldb-dev]

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

George Rimar  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from George Rimar  ---
r351313

-- 
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] [8.0.0 Release] The release branch is here; trunk is now 9.0.0

[Hans Wennborg via lldb-dev]

Hello everyone,

The release branch for LLVM 8 and its sub-projects was created from
trunk at r351319 earlier today, and the trunk version was subsequently
bumped to 9.0.0.

Release blockers are tracked by https://llvm.org/PR40331 Please mark
any bugs, old or new, that need to be fixed before the release as
blocking that.

To get a change committed to the branch, first commit it to trunk as
usual, and then request it to be merged -- ideally by filing a blocker
bug on https://llvm.org/PR40331, or by cc'ing me on the commit email.
(Please don't request merges over IRC, as such requests are easy to
miss.)

Please help with the release by notifying me about any bugs, commits,
or other issues you think might be relevant. If it's not already
marked as blocking the release bug, or I'm not cc'd on an email about
it, I will probably miss it.

What's next? In a day or two, once the branch is in good shape, the
first release candidate (RC1) will be tagged and testing of that can
begin. The release schedule can be found under "Upcoming Releases" to
the right at https://llvm.org.

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

Re: [lldb-dev] [Reproducers] SBReproducer RFC

[Jonas Devlieghere via lldb-dev]

I've put up a (WIP) patch for the tool (https://reviews.llvm.org/D56822) in
case anybody is curious about that.

On Tue, Jan 15, 2019 at 1:41 PM Jonas Devlieghere 
wrote:

> I've updated the patch with a new version of the prototype:
> https://reviews.llvm.org/D56322
>
> It uses Pavel's suggestion to use the function address as a runtime ID.
> All the deserialization code is generated using templates, with automatic
> mapping on indices during serialization and deserialization.
>
> I (again) manually added the macros for the same set of functions I had in
> the original prototype. Unsurprisingly this is very error-prone. It's easy
> to forget to add the right macros for the registry, the function, and the
> return type. Some of these things can be detected at compile time, other
> only blow up at run-time. I strongly believe that a tool to add the macros
> is the way forward. It would be more of a developer tool rather than
> something that hooks up in the build process.
>
> Note that it's still a prototype, there are outstanding issues like void
> pointers, callbacks and other types of argument that require some kind of
> additional information to serialize. I also didn't get around yet to the
> lifetime issue yet that was discussed on IRC last week.
>
> Please let me know what you think.
>
> Thanks,
> Jonas
>
> On Wed, Jan 9, 2019 at 8:58 AM Jonas Devlieghere 
> wrote:
>
>>
>>
>> On Wed, Jan 9, 2019 at 8:42 AM Pavel Labath  wrote:
>>
>>> On 09/01/2019 17:15, Jonas Devlieghere wrote:
>>> >
>>> >
>>> > On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath >> > > wrote:
>>> >
>>> > On 08/01/2019 21:57, Jonas Devlieghere wrote:
>>> >  > Before I got around to coding this up I realized you can't take
>>> the
>>> >  > address of constructors in C++, so the function address won't
>>> > work as an
>>> >  > identifier.
>>> >  >
>>> >
>>> > You gave up way too easily. :P
>>> >
>>> >
>>> > I counted on you having something in mind, it sounded too obvious for
>>> > you to have missed.  ;-)
>>> >
>>> > I realized that constructors are going to be tricky, but I didn't
>>> want
>>> > to dive into those details until I knew if you liked the general
>>> idea.
>>> > The most important thing to realize here is that for the identifier
>>> > thingy to work, you don't actually need to use the address of that
>>> > method/constructor as the identifier. It is sufficient to have
>>> > something
>>> > that can be deterministically computed from the function. Then you
>>> can
>>> > use the address of *that* as the identifier.
>>> >
>>> >
>>> > I was thinking about that yesterday. I still feel like it would be
>>> > better to have this mapping all done at compile time. I was
>>> considering
>>> > some kind of constexpr hashing but that sounded overkill.
>>> >
>>>
>>> Well.. most of this is done through template meta-programming, which
>>> _is_ compile-time. And the fact that I have a use for the new
>>> construct/invoke functions I create this way means that even the space
>>> used by those isn't completely wasted (although I'm sure this could be
>>> made smaller with hard-coded IDs). The biggest impact of this I can
>>> think of is the increased number of dynamic relocations that need to be
>>> performed by the loader, as it introduces a bunch of function pointers
>>> floating around. But even that shouldn't too bad as we have plenty of
>>> other sources of dynamic relocs (currently about 4% of the size of
>>> liblldb and 10% of lldb-server).
>>>
>>
>> Yeah of course, it wasn't my intention to critique your approach. I was
>> talking specifically about the mapping (the std::map) in the prototype,
>> something I asked about earlier in the thread. FWIW I think this would be
>> an excellent trade-off is we don't need a tool to generate code for us. I'm
>> hopeful that we can have the gross of the deserialization code generated
>> this way, most of the "special" cases are still pretty similar and dealing
>> with basic types. Anyway, that should become clear later today as I
>> integrate this into the lldb prototype.
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB not loading any debug information on windows

[Christoph Baumann via lldb-dev]

Hey,

I wrote a simple hello-world program to test lldb on windows:

 

  #include 

  int main(int argc, char* argv[]){

printf("hello world");

return(0);

  }

 

Im compiling with ,clang -g main.c -o main.exe', which produces the
outputfiles ,main.exe', ,main.pdb' and ,main.lnk'.

When i'm now firing up lldb and create new target with ,target create
main.exe', lldb does not appear to load any debug information and source
level debugging is not available. Trying to load debug symbols with ,target
symbols add main.pdb' results in ,.does not match any existing module'.

 

Im using Windows 10 pro and llvm tools built from latest source.

 

I wonder if i miss something or if its just lldb not working properly on
windows yet.

 

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

Re: [lldb-dev] LLDB not loading any debug information on windows

[Zachary Turner via lldb-dev]

Can you try clang-cl.exe /Z7 main.cpp instead of a clang.exe command line?
On Wed, Jan 16, 2019 at 10:56 PM Christoph Baumann via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hey,
>
> I wrote a simple hello-world program to test lldb on windows:
>
>
>
>   #include 
>
>   int main(int argc, char* argv[]){
>
> printf(„hello world“);
>
> return(0);
>
>   }
>
>
>
> Im compiling with ‚clang -g main.c -o main.exe‘, which produces the
> outputfiles ‚main.exe‘, ‚main.pdb‘ and ‚main.lnk‘.
>
> When i’m now firing up lldb and create new target with ‚target create
> main.exe‘, lldb does not appear to load any debug information and source
> level debugging is not available. Trying to load debug symbols with ‚target
> symbols add main.pdb‘ results in ‚…does not match any existing module‘.
>
>
>
> Im using Windows 10 pro and llvm tools built from latest source.
>
>
>
> I wonder if i miss something or if its just lldb not working properly on
> windows yet.
>
>
> ___
> 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