[lldb-dev] breakpoint not hit on ppc64

[Konrad Kleine via lldb-dev]

Hi,

I'm on a machine like this:

Linux  #1 SMP Tue Feb 18 16:40:30 EST 2020 ppc64
ppc64 ppc64 GNU/Linux
Red Hat Enterprise Linux Server release 7.8 (Maipo)

It seems that on PPC64 breakpoints are not able to hit, and it doesn't
matter which strategy you choose. Here's an example:

$ scl enable llvm-toolset-9.0 bash

$ clang++ --version
clang version 9.0.1 (Red Hat 9.0.1-1.el7)
Target: powerpc64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/rh/llvm-toolset-9.0/root/usr/bin

$ echo "int main() { return 42; }" > ~/42.cpp

$ clang++ -g ~/42.cpp

Here's an example to set breakpoint by function name:

$ lldb -x -b -o "b main" -o "run" a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (powerpc64le).
(lldb) b main
Breakpoint 1: 2 locations.
(lldb) run
Process 3279 exited with status = 42 (0x002a)

Process 3279 launched: '/root/a.out' (powerpc64le)
(lldb)

Please also notice that the process is identified as "powerpc64le"
even though this is a "powerpc64" machine.

The "-b" flag doesn't cause lldb to exit for some reason as well.

I hope someone with more experience than me with ppc64 can enlighten this:

Here are some findings:

* I'm testing now if the error remains to exist in LLVM master (a day
old or so). Then I will continue with looking at the findings further
below.

* Apparently ‘target list’ gets the architecture wrong and outputs
“ppc64le” instead of “ppc64”. Tom S. found out that this is because
there’s a problem with a list of architectures that’s being search
linearly: 
https://github.com/llvm/llvm-project/blob/0ce3b710b49c7b9ab837d220547aec92564dd78d/lldb/source/Utility/ArchSpec.cpp#L402

* I found that maybe the bug was introduced by this patch but I'm
still validating this: Add initial support to PowerPC64 little endian
(POWER8)
https://reviews.llvm.org/D36804

* I have written a test that just reproduces the wrong identification
of ppc64le instead of ppc64:

https://gist.github.com/kwk/a5febc24fae07f23022d2ff430667cfb

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

[lldb-dev] [Bug 45310] New: Save file fails while debugging is active on Windows

[via lldb-dev]

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

Bug ID: 45310
   Summary: Save file fails while debugging is active on Windows
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: emrekultur...@google.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

On Windows, when LLDB hits a breakpoint in a large source file, the file is
locked and users can no longer edit the file. This causes trouble for users of
IDEs such as Android Studio, where users expect to be able to edit and save
files while they are debugging.

Background: 
LLDB MemoryBuffer uses mmap for files larger than (4 * 4096) bytes. On Windows,
as long as the mapping is active, files cannot be overwritten.

Details:

1. SourceManager keeps m_last_file_sp to remember the most recently used file.
This keeps the mmapped region alive while a breakpoint is hit.

2. SourceFileCache keeps m_file_cache to remember all previously opened files.
This keeps all mmapped regions alive as long as LLDB is running. (see next
item).

3. SourceFileCache.AddSourceFile is broken: It always adds bogus entry to the
cache, and therefore, cache insertions always conflict and cache lookups never
hit.

// Android Studio reported bug: https://issuetracker.google.com/143436652

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

[lldb-dev] [Bug 45310] Save file fails while debugging is active on Windows

[via lldb-dev]

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

Emre Kultursay  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |emrekultur...@google.com

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

[lldb-dev] How to associate a bug and CL?

[Emre Kultursay via lldb-dev]

llvm-project dev noob here.

I opened a Bug  and have some
CLs  to fix them. How do I link the CL
with the bug so that the code reviewer sees what bug I'm fixing?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 03/16/2020 10:18 AM, Roman Lebedev wrote:
> On Mon, Mar 16, 2020 at 8:13 PM Florian Hahn via cfe-dev
>  wrote:
>>
>> Hi,
>>
>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev 
>>  wrote:
>>
>> I've also implemented a notification system using GitHub actions that will 
>> make
>> it possible to subscribe to individual issue tags, so we would enable this 
>> on Monday
>> as well.
>>
>>
>> Does this include sending emails for new bugs to llvm-bugs like bugzilla 
>> does? I am not sure how many people use llvm-bugs, but at least for me it is 
>> how I keep up with new bug reports.
> +1
> 

I have been looking into this over the last week and was able to get something
working that will email llvm-bugs when an issue is opened, closed, or reopened.
Here is an example email, let me know if there is anything else I should add:


FROM: llvmlist...@llvm.org
Reply-To: llvm-b...@lists.llvm.org
Subject: [Issue 11] Another emailer test



https://github.com/llvm/temp-issue-tester/issues/11

Title: Another emailer test
Reporter: tstellar
State: open


Test description.


-Tom

> 
>> Cheers,
>> Florian
> Roman
> 
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

On 03/16/2020 07:53 AM, Aaron Ballman wrote:
> On Mon, Mar 16, 2020 at 10:44 AM Tom Stellard via cfe-dev
>  wrote:
>>
>> On 02/10/2020 07:40 PM, Tom Stellard wrote:
>>> On 01/30/2020 12:47 PM, David Major wrote:
 Would it make sense to wait until 10.0.0 is released, in order to keep all 
 the blockers in one place?

>>>
>>> Yes, I think this makes sense, let's postpone until then.
>>>
>>
>> Hi,
>>
>> 10.0.0-rc4 was just released, and I think we are at the point in the release 
>> cycle
>> where it is safe to begin the migration to GitHub issues.
>>
>> I would like to propose doing the migration in one week (March 23).  This 
>> means
>> making the existing bugzilla read-only, and updating the documentation to 
>> tell users
>> to file issues at GitHub.  We are still trying to figure out the best way to 
>> import bugs
>> from bugzilla into GitHub, so this step will be done at a later date.
>>
>> For the initial list of tags, I propose we generate the list based on the 
>> most commonly
>> used categories in bugzilla.  This should be enough to get us started and we 
>> can always
>> add more tags as we go.
>>
>> I've also implemented a notification system using GitHub actions that will 
>> make
>> it possible to subscribe to individual issue tags, so we would enable this 
>> on Monday
>> as well.
>>
>> What does everyone think?
> 
> I am uncomfortable switching to GitHub issues unless the initial
> result is that we have ONE set of bugs to track (I do not want to have
> to search and maintain separate bug lists). Moving bugs from Bugzilla
> at an unspecified future time is a deal-breaker for me, so -1.

Is there anything we could do to make having active issues in both
trackers easier to deal with?  

-Tom

> 
> ~Aaron
> 
>>
>> Thanks,
>> Tom
>>
>>
>>> -Tom
>>>


 On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev 
 mailto:llvm-...@lists.llvm.org>> wrote:

 On 01/30/2020 10:24 AM, Aaron Ballman wrote:
 > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
 > mailto:cfe-...@lists.llvm.org>> wrote:
 >>
 >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
 >>> We held a round-table at the llvm dev conference about what other 
 pieces of Github infrastructure we may want to use. This thread in 
 particular is about switching to github issue tracking. Use of other parts 
 of Github functionality was also discussed -- but that should be for other 
 email threads.
 >>>
 >>> Most of the ideas here were from other people. I /believe/ this 
 proposal represents the overall feeling of the folks at the round-table, 
 in spirit if not in exact details, but nobody else has reviewed this text, 
 so I can't make any specific such claim as to who the "we" represents, 
 other than myself. Just assume all the good ideas here were from others, 
 and all the bad parts I misremembered or invented.
 >>>
 >>>
 >>
 >> Hi,
 >>
 >> I want to restart this discussion.  There seemed to be support for 
 this,
 >> but we got held up trying to decide on the appropriate set of tags 
 to
 >> use to classify issues.
 >>
 >> I propose that we move forward with this proposal and disable 
 creation of
 >> new bugs in bugzilla on Feb 11, and require all new bugs be filed 
 via GitHub
 >> issues from that date forward.
 >>
 >> I think that for choosing the tags to use, we should just take 
 requests
 >> from the community over the next week and add whatever is asked 
 for.  The main
 >> purpose of adding tags is so we can setup cc lists for bugs, so I 
 think this
 >> is a good way to ensure that we have tags people care about.  We 
 can always
 >> add more tags later if necessary.
 >>
 >> What does everyone think about this?
 >
 > What did we decide to do with all the existing issues in Bugzilla?
 >

 This is undecided.  The first step of this  proposal only affects new 
 issues.
 Existing issues will remain in bugzilla and will be updated there too. 
  At
 some point in the future bugzilla will become read-only and/or the 
 issues will
 be migrated somewhere else, but no decision has been made about how to 
 do that yet.

 -Tom

 > ~Aaron
 >
 >>
 >> -Tom
 >>
 >>
 >>> Background
 >>> 
 >>> Our bugzilla installation is...not great. It's been not-great for 
 a long time now.
 >>>
 >>> Last year, I argued against switching to github issues. I was 
 somewhat optimistic that it was possible to improve our bugzilla in some 
 incremental ways...but we haven't. Additionally, the upstream bugzilla 
 project was supposed