Re: [lldb-dev] [llvm-dev] Updates on SVN to GitHub migration

[Nico Weber via lldb-dev]

What's the status here?

Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html updated
with the current status of things?

And once things are usable, probably update
https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
as well.

On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On 2018-10-24 08:25, Whisperity via cfe-dev wrote:
> > They are not shown in the project graph, but if you open the "branch"
> > drop down it has a tab named 'Tags'.
>
> It shows some tags there, but not all of them. But clicking "releases"
> then "Tags" will show this page [1], which seems to include all of them.
>
> [1] https://github.com/llvm-git-prototype/llvm/tags
>
> --
> /Jacob Carlborg
>
> ___
> 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] [Call for Volunteers] Bug triaging

[Kristof Beyls via lldb-dev]

Hi,

Yesterday, I’ve landed a description for how reported bugs should be flowing 
through the various stages of a bug’s life (triage, fixing, closing, …) at 
http://llvm.org/docs/BugLifeCycle.html.
Thanks for the many many people who provided ideas and feedback for this!

With there now being a description of what is expected during bug triaging 
(http://llvm.org/docs/BugLifeCycle.html#triaging-bugs), we're looking for more 
volunteers to actually do the bug triaging.
About half of all raised bugs currently don’t seem to get triaged.

The idea is to have one or more volunteers for each of the well over 100 
different product/component combinations we have in bugzilla.
If you volunteer to help with triaging bugs against a specific component, we’ll 
add you to the default cc list for that component, so that when a new bug is 
raised against that component, you’ll get notified automatically through email. 
For components with few reported bugs, a single triager may suffice. For the 
high-traffic components, we’ll probably need multiple volunteers.
I’ve provided the list of product/components below that had bugs reported 
against in 2018, together with how many bugs were reported against them this 
year so far, as an indication for which components may need more volunteers.

I do want to highlight the “new-bugs/new bugs”, “clang/-New Bugs” components as 
those tend to be components people file bugs against if they don’t have a clue 
which part of clang/llvm is causing the issue they’re seeing. I believe that 
you don’t need to be an expert to be able to triage most of those bugs. If you 
want to learn more about llvm, volunteering to triage those bugs may be an 
interesting way to learn a lot more yourself.

How can you get added to the default cc list/volunteer?
* Preferred way: raise a bug against “Bugzilla Admin”/“Products” to get 
yourself added to the default cc list of the components of your choice.
* Other way: email bugs-ad...@lists.llvm.org
* Yet another way: just reply to this mail.

Thanks,

Kristof


new-bugs/new bugs: 535 bugs raised in 2018 (so far)
clang/C++: 296 bugs raised in 2018 (so far)
clang/-New Bugs: 260 bugs raised in 2018 (so far)
libraries/Backend: X86: 202 bugs raised in 2018 (so far)
libraries/Scalar Optimizations: 152 bugs raised in 2018 (so far)
clang/Frontend: 120 bugs raised in 2018 (so far)
lld/ELF: 120 bugs raised in 2018 (so far)
clang/Formatter: 108 bugs raised in 2018 (so far)
lldb/All Bugs: 102 bugs raised in 2018 (so far)
clang/LLVM Codegen: 100 bugs raised in 2018 (so far)
clang-tools-extra/clang-tidy: 87 bugs raised in 2018 (so far)
clang/Static Analyzer: 84 bugs raised in 2018 (so far)
libraries/Common Code Generator Code: 78 bugs raised in 2018 (so far)
libc++/All Bugs: 67 bugs raised in 2018 (so far)
lld/COFF: 64 bugs raised in 2018 (so far)
libraries/Backend: AMDGPU: 60 bugs raised in 2018 (so far)
libraries/Loop Optimizer: 44 bugs raised in 2018 (so far)
lld/All Bugs: 30 bugs raised in 2018 (so far)
clang/Driver: 30 bugs raised in 2018 (so far)
Runtime Libraries/libprofile library: 29 bugs raised in 2018 (so far)
libraries/Backend: WebAssembly: 27 bugs raised in 2018 (so far)
libraries/Backend: ARM: 25 bugs raised in 2018 (so far)
clang-tools-extra/Other: 25 bugs raised in 2018 (so far)
libraries/DebugInfo: 25 bugs raised in 2018 (so far)
OpenMP/Clang Compiler Support: 23 bugs raised in 2018 (so far)
compiler-rt/compiler-rt: 21 bugs raised in 2018 (so far)
libraries/Backend: AArch64: 19 bugs raised in 2018 (so far)
clang/C++11: 19 bugs raised in 2018 (so far)
libraries/MC: 18 bugs raised in 2018 (so far)
Build scripts/cmake: 17 bugs raised in 2018 (so far)
clang/Modules: 17 bugs raised in 2018 (so far)
libraries/GlobalISel: 17 bugs raised in 2018 (so far)
OpenMP/Runtime Library: 15 bugs raised in 2018 (so far)
libraries/Global Analyses: 14 bugs raised in 2018 (so far)
libraries/Core LLVM classes: 14 bugs raised in 2018 (so far)
clang/libclang: 14 bugs raised in 2018 (so far)
Documentation/General docs: 13 bugs raised in 2018 (so far)
Packaging/deb packages: 13 bugs raised in 2018 (so far)
libraries/Support Libraries: 13 bugs raised in 2018 (so far)
libraries/Interprocedural Optimizations: 13 bugs raised in 2018 (so far)
libraries/Backend: PowerPC: 11 bugs raised in 2018 (so far)
libraries/Linker: 11 bugs raised in 2018 (so far)
libraries/Transformation Utilities: 11 bugs raised in 2018 (so far)
clang/C++14: 10 bugs raised in 2018 (so far)
clang/Headers: 10 bugs raised in 2018 (so far)
Test Suite/lit: 10 bugs raised in 2018 (so far)
compiler-rt/profile: 10 bugs raised in 2018 (so far)
tools/llvm-objdump: 9 bugs raised in 2018 (so far)
tools/llvm-ar: 8 bugs raised in 2018 (so far)
Polly/Other: 7 bugs raised in 2018 (so far)
Polly/Optimizer: 7 bugs raised in 2018 (so far)
libraries/Register Allocator: 7 bugs raised in 2018 (so far)
tools/llc: 7 bugs raised in 2018 (so far)
XRay/Runtime: 7 bugs raised in 2018 (so far)
Packaging/Window

[lldb-dev] problem resolving symbolic breakpoint on a remote target

[Adrian Harris via lldb-dev]

Hi Everyone,

I'm unable to resolve *symbolic* breakpoints on a gdb-remote target. Address 
breakpoints work fine. I suspect this is probably some form of user-error, but 
I've had no luck figuring it out on my own.

My target has llvm support and lldb has been patched to add a new target as 
well.

Debug information is correct in the image.

My steps are as follows:

(lldb) gdb-remote 
... connection happens
(lldb) image add tile.elf
(lldb) target modules list
[  0] 89569B3D----tile.elf 
(lldb) break main
lldb Target::AddBreakpoint (internal = no) => break_id = 1: name = 
'main'


lldb warning: Tried to add breakpoint site at 0x 
but it was already present.

lldb Added location: 1.1: 
 module = tile.elf
 compile unit = token_pass.c
 function = main
 location = token_pass.c:74
 address = tile.elf[0x0410]
 resolved = false
 hit count = 0   


Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 0x0410

I traced the breakpoint resolving path in lldb and it ultimately fails in this 
function:
addr_t
SectionLoadList::GetSectionLoadAddress(const lldb::SectionSP §ion) const {
 // TODO: add support for the same section having multiple load addresses
 addr_t section_load_addr = LLDB_INVALID_ADDRESS;
 if (section) {
   std::lock_guard guard(m_mutex);
   sect_to_addr_collection::const_iterator pos =
   m_sect_to_addr.find(section.get());

   if (pos != m_sect_to_addr.end())
 section_load_addr = pos->second;
 }
 return section_load_addr;
}

... because the m_sect_to_addr map is not populated. I think that should happen 
in 

bool SectionLoadList::SetSectionLoadAddress(const lldb::SectionSP §ion,
   addr_t load_addr,
   bool warn_multiple) {

.. but it is never called. This is what makes me think I'm leaving out a 
critical step.

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

Re: [lldb-dev] problem resolving symbolic breakpoint on a remote target

[via lldb-dev]

What happens if you do this:

(lldb) file tile.elf
(lldb) b main
(lldb) gdb-remote 

?

--
Ted Woodward
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

-Original Message-
From: lldb-dev  On Behalf Of Adrian Harris via 
lldb-dev
Sent: Thursday, November 8, 2018 11:09 AM
To: via lldb-dev 
Subject: [lldb-dev] problem resolving symbolic breakpoint on a remote target

Hi Everyone,

I'm unable to resolve *symbolic* breakpoints on a gdb-remote target. Address 
breakpoints work fine. I suspect this is probably some form of user-error, but 
I've had no luck figuring it out on my own.

My target has llvm support and lldb has been patched to add a new target as 
well.

Debug information is correct in the image.

My steps are as follows:

(lldb) gdb-remote 
... connection happens
(lldb) image add tile.elf
(lldb) target modules list
[  0] 89569B3D----tile.elf 
(lldb) break main
lldb Target::AddBreakpoint (internal = no) => break_id = 1: name = 
'main'


lldb warning: Tried to add breakpoint site at 0x 
but it was already present.

lldb Added location: 1.1: 
 module = tile.elf
 compile unit = token_pass.c
 function = main
 location = token_pass.c:74
 address = tile.elf[0x0410]
 resolved = false
 hit count = 0   


Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 0x0410

I traced the breakpoint resolving path in lldb and it ultimately fails in this 
function:
addr_t
SectionLoadList::GetSectionLoadAddress(const lldb::SectionSP §ion) const {  
// TODO: add support for the same section having multiple load addresses  
addr_t section_load_addr = LLDB_INVALID_ADDRESS;  if (section) {
   std::lock_guard guard(m_mutex);
   sect_to_addr_collection::const_iterator pos =
   m_sect_to_addr.find(section.get());

   if (pos != m_sect_to_addr.end())
 section_load_addr = pos->second;
 }
 return section_load_addr;
}

... because the m_sect_to_addr map is not populated. I think that should happen 
in 

bool SectionLoadList::SetSectionLoadAddress(const lldb::SectionSP §ion,
   addr_t load_addr,
   bool warn_multiple) {

.. but it is never called. This is what makes me think I'm leaving out a 
critical step.

Thanks for any help,
Adrian
___
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

Re: [lldb-dev] problem resolving symbolic breakpoint on a remote target

[Adrian Harris via lldb-dev]

(lldb) file tile.elf
Current executable set to 'tile.elf' (cs).
(lldb) b main
lldb Target::AddBreakpoint (internal = no) => break_id = 1: name = 
'main'


lldb Added location: 1.1: 
  module = tile.elf
  compile unit = token_pass.c
  function = main
  location = token_pass.c:74
  address = tile.elf[0x0410]
  resolved = false
  hit count = 0   


Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 0x0410
(lldb) gdb-remote server4:33722
Process 1 stopped
* thread #1, stop reason = signal SIGTRAP
frame #0: 0x0422
tile.elf`main:
tile.elf[0x422] <+34>: eq16   r5, 0
tile.elf[0x424] <+36>: addc16 r0 = r7, 0
tile.elf[0x428] <+40>: eq16   r0, r7
tile.elf[0x42a] <+42>: jc 0xb
(lldb) break list
Current breakpoints:
1: name = 'main', locations = 1
  1.1: where = tile.elf`main + 16 at token_pass.c:74, address = 
tile.elf[0x0410], unresolved, hit count = 0 

So it is still not resolved.

Adrian


> On Nov 8, 2018, at 11:06 AM, ted.woodw...@codeaurora.org wrote:
> 
> What happens if you do this:
> 
> (lldb) file tile.elf
> (lldb) b main
> (lldb) gdb-remote 
> 
> ?
> 
> --
> Ted Woodward
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
> Foundation Collaborative Project
> 
> -Original Message-
> From: lldb-dev  On Behalf Of Adrian Harris 
> via lldb-dev
> Sent: Thursday, November 8, 2018 11:09 AM
> To: via lldb-dev 
> Subject: [lldb-dev] problem resolving symbolic breakpoint on a remote target
> 
> Hi Everyone,
> 
> I'm unable to resolve *symbolic* breakpoints on a gdb-remote target. Address 
> breakpoints work fine. I suspect this is probably some form of user-error, 
> but I've had no luck figuring it out on my own.
> 
> My target has llvm support and lldb has been patched to add a new target as 
> well.
> 
> Debug information is correct in the image.
> 
> My steps are as follows:
> 
> (lldb) gdb-remote 
> ... connection happens
> (lldb) image add tile.elf
> (lldb) target modules list
> [  0] 89569B3D----tile.elf 
> (lldb) break main
> lldb Target::AddBreakpoint (internal = no) => break_id = 1: name 
> = 'main'
> 
> 
> lldb warning: Tried to add breakpoint site at 0x 
> but it was already present.
> 
> lldb Added location: 1.1: 
> module = tile.elf
> compile unit = token_pass.c
> function = main
> location = token_pass.c:74
> address = tile.elf[0x0410]
> resolved = false
> hit count = 0   
> 
> 
> Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 0x0410
> 
> I traced the breakpoint resolving path in lldb and it ultimately fails in 
> this function:
> addr_t
> SectionLoadList::GetSectionLoadAddress(const lldb::SectionSP §ion) const 
> {  // TODO: add support for the same section having multiple load addresses  
> addr_t section_load_addr = LLDB_INVALID_ADDRESS;  if (section) {
>   std::lock_guard guard(m_mutex);
>   sect_to_addr_collection::const_iterator pos =
>   m_sect_to_addr.find(section.get());
> 
>   if (pos != m_sect_to_addr.end())
> section_load_addr = pos->second;
> }
> return section_load_addr;
> }
> 
> ... because the m_sect_to_addr map is not populated. I think that should 
> happen in 
> 
> bool SectionLoadList::SetSectionLoadAddress(const lldb::SectionSP §ion,
>   addr_t load_addr,
>   bool warn_multiple) {
> 
> .. but it is never called. This is what makes me think I'm leaving out a 
> critical step.
> 
> Thanks for any help,
> Adrian
> ___
> 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

Re: [lldb-dev] problem resolving symbolic breakpoint on a remote target

[Jim Ingham via lldb-dev]

lldb finds the symbol you asked for in the elf file's symbols, and makes a 
"location" for that address in that binary (as a section-relative address).  
But that won't help it actually SET the breakpoint, since that doesn't tell us 
where that section will end up in the executable image when it runs.  It is the 
job of the DynamicLoader plugin for whatever platform you are debugging to 
observe a process as it is getting launched and register where all the sections 
land memory.  The section load map is the storage for this information.  If 
that isn't getting filled in then we won't be able to actually set the 
breakpoint in the target.  It sounds like the Dynamic Loader step is missing.

Jim


> On Nov 8, 2018, at 10:20 AM, Adrian Harris via lldb-dev 
>  wrote:
> 
> (lldb) file tile.elf
> Current executable set to 'tile.elf' (cs).
> (lldb) b main
> lldb Target::AddBreakpoint (internal = no) => break_id = 1: name 
> = 'main'
> 
> 
> lldb Added location: 1.1: 
>  module = tile.elf
>  compile unit = token_pass.c
>  function = main
>  location = token_pass.c:74
>  address = tile.elf[0x0410]
>  resolved = false
>  hit count = 0   
> 
> 
> Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 0x0410
> (lldb) gdb-remote server4:33722
> Process 1 stopped
> * thread #1, stop reason = signal SIGTRAP
>frame #0: 0x0422
> tile.elf`main:
>tile.elf[0x422] <+34>: eq16   r5, 0
>tile.elf[0x424] <+36>: addc16 r0 = r7, 0
>tile.elf[0x428] <+40>: eq16   r0, r7
>tile.elf[0x42a] <+42>: jc 0xb
> (lldb) break list
> Current breakpoints:
> 1: name = 'main', locations = 1
>  1.1: where = tile.elf`main + 16 at token_pass.c:74, address = 
> tile.elf[0x0410], unresolved, hit count = 0 
> 
> So it is still not resolved.
> 
> Adrian
> 
> 
>> On Nov 8, 2018, at 11:06 AM, ted.woodw...@codeaurora.org wrote:
>> 
>> What happens if you do this:
>> 
>> (lldb) file tile.elf
>> (lldb) b main
>> (lldb) gdb-remote 
>> 
>> ?
>> 
>> --
>> Ted Woodward
>> Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
>> Foundation Collaborative Project
>> 
>> -Original Message-
>> From: lldb-dev  On Behalf Of Adrian Harris 
>> via lldb-dev
>> Sent: Thursday, November 8, 2018 11:09 AM
>> To: via lldb-dev 
>> Subject: [lldb-dev] problem resolving symbolic breakpoint on a remote target
>> 
>> Hi Everyone,
>> 
>> I'm unable to resolve *symbolic* breakpoints on a gdb-remote target. Address 
>> breakpoints work fine. I suspect this is probably some form of user-error, 
>> but I've had no luck figuring it out on my own.
>> 
>> My target has llvm support and lldb has been patched to add a new target as 
>> well.
>> 
>> Debug information is correct in the image.
>> 
>> My steps are as follows:
>> 
>> (lldb) gdb-remote 
>> ... connection happens
>> (lldb) image add tile.elf
>> (lldb) target modules list
>> [  0] 89569B3D----tile.elf 
>> (lldb) break main
>> lldb Target::AddBreakpoint (internal = no) => break_id = 1: name 
>> = 'main'
>> 
>> 
>> lldb warning: Tried to add breakpoint site at 0x 
>> but it was already present.
>> 
>> lldb Added location: 1.1: 
>> module = tile.elf
>> compile unit = token_pass.c
>> function = main
>> location = token_pass.c:74
>> address = tile.elf[0x0410]
>> resolved = false
>> hit count = 0   
>> 
>> 
>> Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 0x0410
>> 
>> I traced the breakpoint resolving path in lldb and it ultimately fails in 
>> this function:
>> addr_t
>> SectionLoadList::GetSectionLoadAddress(const lldb::SectionSP §ion) const 
>> {  // TODO: add support for the same section having multiple load addresses  
>> addr_t section_load_addr = LLDB_INVALID_ADDRESS;  if (section) {
>>  std::lock_guard guard(m_mutex);
>>  sect_to_addr_collection::const_iterator pos =
>>  m_sect_to_addr.find(section.get());
>> 
>>  if (pos != m_sect_to_addr.end())
>>section_load_addr = pos->second;
>> }
>> return section_load_addr;
>> }
>> 
>> ... because the m_sect_to_addr map is not populated. I think that should 
>> happen in 
>> 
>> bool SectionLoadList::SetSectionLoadAddress(const lldb::SectionSP §ion,
>>  addr_t load_addr,
>>  bool warn_multiple) {
>> 
>> .. but it is never called. This is what makes me think I'm leaving out a 
>> critical step.
>> 
>> Thanks for any help,
>> Adrian
>> ___
>> 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-

Re: [lldb-dev] problem resolving symbolic breakpoint on a remote target

[Adrian Harris via lldb-dev]

Thanks Jim - that makes sense for the types of targets that lldb interacts with 
mostly.

In my particular case, nothing is getting 'launched' - rather I'm attaching to 
an already running target. The elf that I'm pointing to is an exact executable 
image as the target has no OS to speak of and is very primitive.

Would it make sense to write a simple process plugin for my target? I'm a 
little fuzzy on exactly how the 'process' interacts with the gdb-remote target 
in lldb however.

More generally, how does lldb figure out where symbols are in an arbitrary 
target when the use mode is attach, as opposed to launching the process 
(therefore learning the layout).

Adrian



> On Nov 8, 2018, at 11:36 AM, Jim Ingham  wrote:
> 
> lldb finds the symbol you asked for in the elf file's symbols, and makes a 
> "location" for that address in that binary (as a section-relative address).  
> But that won't help it actually SET the breakpoint, since that doesn't tell 
> us where that section will end up in the executable image when it runs.  It 
> is the job of the DynamicLoader plugin for whatever platform you are 
> debugging to observe a process as it is getting launched and register where 
> all the sections land memory.  The section load map is the storage for this 
> information.  If that isn't getting filled in then we won't be able to 
> actually set the breakpoint in the target.  It sounds like the Dynamic Loader 
> step is missing.
> 
> Jim
> 
> 
>> On Nov 8, 2018, at 10:20 AM, Adrian Harris via lldb-dev 
>>  wrote:
>> 
>> (lldb) file tile.elf
>> Current executable set to 'tile.elf' (cs).
>> (lldb) b main
>> lldb Target::AddBreakpoint (internal = no) => break_id = 1: name 
>> = 'main'
>> 
>> 
>> lldb Added location: 1.1: 
>> module = tile.elf
>> compile unit = token_pass.c
>> function = main
>> location = token_pass.c:74
>> address = tile.elf[0x0410]
>> resolved = false
>> hit count = 0   
>> 
>> 
>> Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 0x0410
>> (lldb) gdb-remote server4:33722
>> Process 1 stopped
>> * thread #1, stop reason = signal SIGTRAP
>>   frame #0: 0x0422
>> tile.elf`main:
>>   tile.elf[0x422] <+34>: eq16   r5, 0
>>   tile.elf[0x424] <+36>: addc16 r0 = r7, 0
>>   tile.elf[0x428] <+40>: eq16   r0, r7
>>   tile.elf[0x42a] <+42>: jc 0xb
>> (lldb) break list
>> Current breakpoints:
>> 1: name = 'main', locations = 1
>> 1.1: where = tile.elf`main + 16 at token_pass.c:74, address = 
>> tile.elf[0x0410], unresolved, hit count = 0 
>> 
>> So it is still not resolved.
>> 
>> Adrian
>> 
>> 
>>> On Nov 8, 2018, at 11:06 AM, ted.woodw...@codeaurora.org wrote:
>>> 
>>> What happens if you do this:
>>> 
>>> (lldb) file tile.elf
>>> (lldb) b main
>>> (lldb) gdb-remote 
>>> 
>>> ?
>>> 
>>> --
>>> Ted Woodward
>>> Qualcomm Innovation Center, Inc.
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
>>> Foundation Collaborative Project
>>> 
>>> -Original Message-
>>> From: lldb-dev  On Behalf Of Adrian Harris 
>>> via lldb-dev
>>> Sent: Thursday, November 8, 2018 11:09 AM
>>> To: via lldb-dev 
>>> Subject: [lldb-dev] problem resolving symbolic breakpoint on a remote target
>>> 
>>> Hi Everyone,
>>> 
>>> I'm unable to resolve *symbolic* breakpoints on a gdb-remote target. 
>>> Address breakpoints work fine. I suspect this is probably some form of 
>>> user-error, but I've had no luck figuring it out on my own.
>>> 
>>> My target has llvm support and lldb has been patched to add a new target as 
>>> well.
>>> 
>>> Debug information is correct in the image.
>>> 
>>> My steps are as follows:
>>> 
>>> (lldb) gdb-remote 
>>> ... connection happens
>>> (lldb) image add tile.elf
>>> (lldb) target modules list
>>> [  0] 89569B3D----tile.elf 
>>> (lldb) break main
>>> lldb Target::AddBreakpoint (internal = no) => break_id = 1: 
>>> name = 'main'
>>> 
>>> 
>>> lldb warning: Tried to add breakpoint site at 
>>> 0x but it was already present.
>>> 
>>> lldb Added location: 1.1: 
>>> module = tile.elf
>>> compile unit = token_pass.c
>>> function = main
>>> location = token_pass.c:74
>>> address = tile.elf[0x0410]
>>> resolved = false
>>> hit count = 0   
>>> 
>>> 
>>> Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 
>>> 0x0410
>>> 
>>> I traced the breakpoint resolving path in lldb and it ultimately fails in 
>>> this function:
>>> addr_t
>>> SectionLoadList::GetSectionLoadAddress(const lldb::SectionSP §ion) 
>>> const {  // TODO: add support for the same section having multiple load 
>>> addresses  addr_t section_load_addr = LLDB_INVALID_ADDRESS;  if (section) {
>>> std::lock_guard guard(m_mutex);
>>> sect_to_addr_collection::const_iterator pos =
>>> m_sect_to_addr.find(section.get());
>>> 
>>> if (pos != m_sect_to_addr.end())
>>>   section_load_addr = pos->second;
>>> }
>>> return section_load_addr;
>>> }
>>> 
>>> ... becaus

Re: [lldb-dev] problem resolving symbolic breakpoint on a remote target

[Jim Ingham via lldb-dev]

> On Nov 8, 2018, at 11:18 AM, Adrian Harris  wrote:
> 
> Thanks Jim - that makes sense for the types of targets that lldb interacts 
> with mostly.
> 
> In my particular case, nothing is getting 'launched' - rather I'm attaching 
> to an already running target. The elf that I'm pointing to is an exact 
> executable image as the target has no OS to speak of and is very primitive.
> 
> Would it make sense to write a simple process plugin for my target? I'm a 
> little fuzzy on exactly how the 'process' interacts with the gdb-remote 
> target in lldb however.
> 

What you need is a DynamicLoader for the OS you are targeting.  The 
ProcessGDBRemote queries all the loaded DynamicLoader plugins for the one that 
matches the current process, and installs the one that matches.  Then that 
plugin has the job of filling in the section load list.  In your case, that 
would just be to copy all the section addresses directly to the section load 
map.

> More generally, how does lldb figure out where symbols are in an arbitrary 
> target when the use mode is attach, as opposed to launching the process 
> (therefore learning the layout).

That's handled the same way as launch.  When you attach, lldb gets host info 
from the other side of the connection (you can also help this out by providing 
an appropriate triple when you create the target before attaching).  It uses 
that to figure out which DynamicLoader plugin to use.  And again, it's the 
DynamicLoader's job to look at the memory of the target process and figure out 
where the images got mapped.  How it does that is magic specific to each plugin.

JIm


> 
> Adrian
> 
> 
> 
>> On Nov 8, 2018, at 11:36 AM, Jim Ingham  wrote:
>> 
>> lldb finds the symbol you asked for in the elf file's symbols, and makes a 
>> "location" for that address in that binary (as a section-relative address).  
>> But that won't help it actually SET the breakpoint, since that doesn't tell 
>> us where that section will end up in the executable image when it runs.  It 
>> is the job of the DynamicLoader plugin for whatever platform you are 
>> debugging to observe a process as it is getting launched and register where 
>> all the sections land memory.  The section load map is the storage for this 
>> information.  If that isn't getting filled in then we won't be able to 
>> actually set the breakpoint in the target.  It sounds like the Dynamic 
>> Loader step is missing.
>> 
>> Jim
>> 
>> 
>>> On Nov 8, 2018, at 10:20 AM, Adrian Harris via lldb-dev 
>>>  wrote:
>>> 
>>> (lldb) file tile.elf
>>> Current executable set to 'tile.elf' (cs).
>>> (lldb) b main
>>> lldb Target::AddBreakpoint (internal = no) => break_id = 1: 
>>> name = 'main'
>>> 
>>> 
>>> lldb Added location: 1.1: 
>>> module = tile.elf
>>> compile unit = token_pass.c
>>> function = main
>>> location = token_pass.c:74
>>> address = tile.elf[0x0410]
>>> resolved = false
>>> hit count = 0   
>>> 
>>> 
>>> Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address = 
>>> 0x0410
>>> (lldb) gdb-remote server4:33722
>>> Process 1 stopped
>>> * thread #1, stop reason = signal SIGTRAP
>>>  frame #0: 0x0422
>>> tile.elf`main:
>>>  tile.elf[0x422] <+34>: eq16   r5, 0
>>>  tile.elf[0x424] <+36>: addc16 r0 = r7, 0
>>>  tile.elf[0x428] <+40>: eq16   r0, r7
>>>  tile.elf[0x42a] <+42>: jc 0xb
>>> (lldb) break list
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1
>>> 1.1: where = tile.elf`main + 16 at token_pass.c:74, address = 
>>> tile.elf[0x0410], unresolved, hit count = 0 
>>> 
>>> So it is still not resolved.
>>> 
>>> Adrian
>>> 
>>> 
 On Nov 8, 2018, at 11:06 AM, ted.woodw...@codeaurora.org wrote:
 
 What happens if you do this:
 
 (lldb) file tile.elf
 (lldb) b main
 (lldb) gdb-remote 
 
 ?
 
 --
 Ted Woodward
 Qualcomm Innovation Center, Inc.
 Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
 Foundation Collaborative Project
 
 -Original Message-
 From: lldb-dev  On Behalf Of Adrian 
 Harris via lldb-dev
 Sent: Thursday, November 8, 2018 11:09 AM
 To: via lldb-dev 
 Subject: [lldb-dev] problem resolving symbolic breakpoint on a remote 
 target
 
 Hi Everyone,
 
 I'm unable to resolve *symbolic* breakpoints on a gdb-remote target. 
 Address breakpoints work fine. I suspect this is probably some form of 
 user-error, but I've had no luck figuring it out on my own.
 
 My target has llvm support and lldb has been patched to add a new target 
 as well.
 
 Debug information is correct in the image.
 
 My steps are as follows:
 
 (lldb) gdb-remote 
 ... connection happens
 (lldb) image add tile.elf
 (lldb) target modules list
 [  0] 89569B3D----tile.elf 
 (lldb) break main
 lldb Target::AddBreakpoint (internal = no) => break_id = 1: 
 name 

Re: [lldb-dev] [cfe-dev] [Call for Volunteers] Bug triaging

[Zachary Turner via lldb-dev]

Just so I'm clear, are we going to attempt to clean up and/or merge the
components?  If we are, it makes sense to do that before we start putting
ourselves as default CC's on the various components since they will just
change.  If not, it would be nice to get some clarification on that now.

I've put the above list into a spreadsheet so people can sort / filter it
as they see fit.  The link is here:

https://docs.google.com/spreadsheets/d/1aeU6P_vN2c63mpkilqni26U7XtEBDbzZYPFnovwr3FI/edit#gid=0

I think a good starting point would be to get rid of any component with
less than 10 bugs reported so far this year and merge them all into an
"Other" component.

On Thu, Nov 8, 2018 at 8:11 AM Kristof Beyls via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> Hi,
>
> Yesterday, I’ve landed a description for how reported bugs should be
> flowing through the various stages of a bug’s life (triage, fixing,
> closing, …) at http://llvm.org/docs/BugLifeCycle.html.
> Thanks for the many many people who provided ideas and feedback for this!
>
> With there now being a description of what is expected during bug triaging
> (http://llvm.org/docs/BugLifeCycle.html#triaging-bugs), we're looking for
> more volunteers to actually do the bug triaging.
> About half of all raised bugs currently don’t seem to get triaged.
>
> The idea is to have one or more volunteers for each of the well over 100
> different product/component combinations we have in bugzilla.
> If you volunteer to help with triaging bugs against a specific component,
> we’ll add you to the default cc list for that component, so that when a new
> bug is raised against that component, you’ll get notified automatically
> through email. For components with few reported bugs, a single triager may
> suffice. For the high-traffic components, we’ll probably need multiple
> volunteers.
> I’ve provided the list of product/components below that had bugs reported
> against in 2018, together with how many bugs were reported against them
> this year so far, as an indication for which components may need more
> volunteers.
>
> I do want to highlight the “new-bugs/new bugs”, “clang/-New Bugs”
> components as those tend to be components people file bugs against if they
> don’t have a clue which part of clang/llvm is causing the issue they’re
> seeing. I believe that you don’t need to be an expert to be able to triage
> most of those bugs. If you want to learn more about llvm, volunteering to
> triage those bugs may be an interesting way to learn a lot more yourself.
>
> How can you get added to the default cc list/volunteer?
> * Preferred way: raise a bug against “Bugzilla Admin”/“Products” to get
> yourself added to the default cc list of the components of your choice.
> * Other way: email bugs-ad...@lists.llvm.org
> * Yet another way: just reply to this mail.
>
> Thanks,
>
> Kristof
>
> new-bugs/new bugs: 535 bugs raised in 2018 (so far)
> clang/C++: 296 bugs raised in 2018 (so far)
> clang/-New Bugs: 260 bugs raised in 2018 (so far)
> libraries/Backend: X86: 202 bugs raised in 2018 (so far)
> libraries/Scalar Optimizations: 152 bugs raised in 2018 (so far)
> clang/Frontend: 120 bugs raised in 2018 (so far)
> lld/ELF: 120 bugs raised in 2018 (so far)
> clang/Formatter: 108 bugs raised in 2018 (so far)
> lldb/All Bugs: 102 bugs raised in 2018 (so far)
> clang/LLVM Codegen: 100 bugs raised in 2018 (so far)
> clang-tools-extra/clang-tidy: 87 bugs raised in 2018 (so far)
> clang/Static Analyzer: 84 bugs raised in 2018 (so far)
> libraries/Common Code Generator Code: 78 bugs raised in 2018 (so far)
> libc++/All Bugs: 67 bugs raised in 2018 (so far)
> lld/COFF: 64 bugs raised in 2018 (so far)
> libraries/Backend: AMDGPU: 60 bugs raised in 2018 (so far)
> libraries/Loop Optimizer: 44 bugs raised in 2018 (so far)
> lld/All Bugs: 30 bugs raised in 2018 (so far)
> clang/Driver: 30 bugs raised in 2018 (so far)
> Runtime Libraries/libprofile library: 29 bugs raised in 2018 (so far)
> libraries/Backend: WebAssembly: 27 bugs raised in 2018 (so far)
> libraries/Backend: ARM: 25 bugs raised in 2018 (so far)
> clang-tools-extra/Other: 25 bugs raised in 2018 (so far)
> libraries/DebugInfo: 25 bugs raised in 2018 (so far)
> OpenMP/Clang Compiler Support: 23 bugs raised in 2018 (so far)
> compiler-rt/compiler-rt: 21 bugs raised in 2018 (so far)
> libraries/Backend: AArch64: 19 bugs raised in 2018 (so far)
> clang/C++11: 19 bugs raised in 2018 (so far)
> libraries/MC: 18 bugs raised in 2018 (so far)
> Build scripts/cmake: 17 bugs raised in 2018 (so far)
> clang/Modules: 17 bugs raised in 2018 (so far)
> libraries/GlobalISel: 17 bugs raised in 2018 (so far)
> OpenMP/Runtime Library: 15 bugs raised in 2018 (so far)
> libraries/Global Analyses: 14 bugs raised in 2018 (so far)
> libraries/Core LLVM classes: 14 bugs raised in 2018 (so far)
> clang/libclang: 14 bugs raised in 2018 (so far)
> Documentation/General docs: 13 bugs raised in 2018 (so far)
> Packaging/deb packages: 13 bugs raised in 2018 (so far)
> li

Re: [lldb-dev] problem resolving symbolic breakpoint on a remote target

[via lldb-dev]

You're probably going to want to use the Static DYLD plugin.

--
Ted Woodward
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-Original Message-
From: jing...@apple.com  
Sent: Thursday, November 8, 2018 1:39 PM
To: Adrian Harris 
Cc: ted.woodw...@codeaurora.org; LLDB 
Subject: Re: [lldb-dev] problem resolving symbolic breakpoint on a remote
target



> On Nov 8, 2018, at 11:18 AM, Adrian Harris  wrote:
> 
> Thanks Jim - that makes sense for the types of targets that lldb interacts
with mostly.
> 
> In my particular case, nothing is getting 'launched' - rather I'm
attaching to an already running target. The elf that I'm pointing to is an
exact executable image as the target has no OS to speak of and is very
primitive.
> 
> Would it make sense to write a simple process plugin for my target? I'm a
little fuzzy on exactly how the 'process' interacts with the gdb-remote
target in lldb however.
> 

What you need is a DynamicLoader for the OS you are targeting.  The
ProcessGDBRemote queries all the loaded DynamicLoader plugins for the one
that matches the current process, and installs the one that matches.  Then
that plugin has the job of filling in the section load list.  In your case,
that would just be to copy all the section addresses directly to the section
load map.

> More generally, how does lldb figure out where symbols are in an arbitrary
target when the use mode is attach, as opposed to launching the process
(therefore learning the layout).

That's handled the same way as launch.  When you attach, lldb gets host info
from the other side of the connection (you can also help this out by
providing an appropriate triple when you create the target before
attaching).  It uses that to figure out which DynamicLoader plugin to use.
And again, it's the DynamicLoader's job to look at the memory of the target
process and figure out where the images got mapped.  How it does that is
magic specific to each plugin.

JIm


> 
> Adrian
> 
> 
> 
>> On Nov 8, 2018, at 11:36 AM, Jim Ingham  wrote:
>> 
>> lldb finds the symbol you asked for in the elf file's symbols, and makes
a "location" for that address in that binary (as a section-relative
address).  But that won't help it actually SET the breakpoint, since that
doesn't tell us where that section will end up in the executable image when
it runs.  It is the job of the DynamicLoader plugin for whatever platform
you are debugging to observe a process as it is getting launched and
register where all the sections land memory.  The section load map is the
storage for this information.  If that isn't getting filled in then we won't
be able to actually set the breakpoint in the target.  It sounds like the
Dynamic Loader step is missing.
>> 
>> Jim
>> 
>> 
>>> On Nov 8, 2018, at 10:20 AM, Adrian Harris via lldb-dev
 wrote:
>>> 
>>> (lldb) file tile.elf
>>> Current executable set to 'tile.elf' (cs).
>>> (lldb) b main
>>> lldb Target::AddBreakpoint (internal = no) => break_id = 1:
name = 'main'
>>> 
>>> 
>>> lldb Added location: 1.1: 
>>> module = tile.elf
>>> compile unit = token_pass.c
>>> function = main
>>> location = token_pass.c:74
>>> address = tile.elf[0x0410]
>>> resolved = false
>>> hit count = 0   
>>> 
>>> 
>>> Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address 
>>> = 0x0410
>>> (lldb) gdb-remote server4:33722
>>> Process 1 stopped
>>> * thread #1, stop reason = signal SIGTRAP  frame #0: 0x0422
>>> tile.elf`main:
>>>  tile.elf[0x422] <+34>: eq16   r5, 0
>>>  tile.elf[0x424] <+36>: addc16 r0 = r7, 0
>>>  tile.elf[0x428] <+40>: eq16   r0, r7
>>>  tile.elf[0x42a] <+42>: jc 0xb
>>> (lldb) break list
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1
>>> 1.1: where = tile.elf`main + 16 at token_pass.c:74, address = 
>>> tile.elf[0x0410], unresolved, hit count = 0
>>> 
>>> So it is still not resolved.
>>> 
>>> Adrian
>>> 
>>> 
 On Nov 8, 2018, at 11:06 AM, ted.woodw...@codeaurora.org wrote:
 
 What happens if you do this:
 
 (lldb) file tile.elf
 (lldb) b main
 (lldb) gdb-remote 
 
 ?
 
 --
 Ted Woodward
 Qualcomm Innovation Center, Inc.
 Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
 a Linux Foundation Collaborative Project
 
 -Original Message-
 From: lldb-dev  On Behalf Of 
 Adrian Harris via lldb-dev
 Sent: Thursday, November 8, 2018 11:09 AM
 To: via lldb-dev 
 Subject: [lldb-dev] problem resolving symbolic breakpoint on a 
 remote target
 
 Hi Everyone,
 
 I'm unable to resolve *symbolic* breakpoints on a gdb-remote target.
Address breakpoints work fine. I suspect this is probably some form of
user-error, but I've had no luck figuring it out on my own.
 
 My target has llvm support and lldb has been patched to add a new
target as well.
 
 Debug information is co

Re: [lldb-dev] [llvm-dev] [cfe-dev] [Call for Volunteers] Bug triaging

[David Greene via lldb-dev]

Zachary Turner via llvm-dev  writes:

> Just so I'm clear, are we going to attempt to clean up and/or merge
> the components? If we are, it makes sense to do that before we start
> putting ourselves as default CC's on the various components since they
> will just change. If not, it would be nice to get some clarification
> on that now.

I agree that we could use component cleanup and that it should happen
before assigning triagers.

> I think a good starting point would be to get rid of any component
> with less than 10 bugs reported so far this year and merge them all
> into an "Other" component.

Here's how I might organize things, given a clean slate:

Bugzilla

Build

clang/driver
clang/frontend
clang/llvm
clang/tools

compiler-rt

Documentation

libc++
libc++-abi

llvm/optimizer
llvm/codegen

lld

lldb

LNT

OpenMP

Packaging

Phabricator

Polly

Test Suite

Tools

Triage   # Replaces new-bugs

Website

These are not necessarily restricted to particular directory structures.
For example, an "lld" bug might very well be against a common library in
under llvm/.  I'm trying to put forward something that would make sense
to users of llvm-based compilers as well as more casual LLVM developers
while providing some categorization for broad topics (the llvm optimizer
is very different from llvm codegen, for example).


I'm not sure what should go under "Tools."  Should it be limited to
things in llvm/tools or should it include things like clang-tidy?  Maybe
we'd want an llvm/tools component and leave Tools for user-facing tools
like the clang static analyzer.  In that case clang/tools can maybe go
away.

Just some ideas.

  -David

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

Re: [lldb-dev] [llvm-dev] Updates on SVN to GitHub migration

[Anton Korobeynikov via lldb-dev]

Some status update wrt GitHub SVN bridge.

It does not work for any non-trivial (= LLVM) repo. I filled the issue
there, however, there is no ETA when it will be fixed. Even worse,
there are no promises that the issue will be addressed at all. Though
they are aware that this is the issue for us.
On Thu, Nov 8, 2018 at 12:53 PM Nico Weber via llvm-dev
 wrote:
>
> What's the status here?
>
> Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html updated with 
> the current status of things?
>
> And once things are usable, probably update 
> https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
>  as well.
>
> On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev 
>  wrote:
>>
>> On 2018-10-24 08:25, Whisperity via cfe-dev wrote:
>> > They are not shown in the project graph, but if you open the "branch"
>> > drop down it has a tab named 'Tags'.
>>
>> It shows some tags there, but not all of them. But clicking "releases"
>> then "Tags" will show this page [1], which seems to include all of them.
>>
>> [1] https://github.com/llvm-git-prototype/llvm/tags
>>
>> --
>> /Jacob Carlborg
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] problem resolving symbolic breakpoint on a remote target

[Adrian Harris via lldb-dev]

Thanks guys! Adding the plugin did the trick.
Adrian

> On Nov 8, 2018, at 1:01 PM, ted.woodw...@codeaurora.org wrote:
> 
> You're probably going to want to use the Static DYLD plugin.
> 
> --
> Ted Woodward
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
> 
> -Original Message-
> From: jing...@apple.com  
> Sent: Thursday, November 8, 2018 1:39 PM
> To: Adrian Harris 
> Cc: ted.woodw...@codeaurora.org; LLDB 
> Subject: Re: [lldb-dev] problem resolving symbolic breakpoint on a remote
> target
> 
> 
> 
>> On Nov 8, 2018, at 11:18 AM, Adrian Harris  wrote:
>> 
>> Thanks Jim - that makes sense for the types of targets that lldb interacts
> with mostly.
>> 
>> In my particular case, nothing is getting 'launched' - rather I'm
> attaching to an already running target. The elf that I'm pointing to is an
> exact executable image as the target has no OS to speak of and is very
> primitive.
>> 
>> Would it make sense to write a simple process plugin for my target? I'm a
> little fuzzy on exactly how the 'process' interacts with the gdb-remote
> target in lldb however.
>> 
> 
> What you need is a DynamicLoader for the OS you are targeting.  The
> ProcessGDBRemote queries all the loaded DynamicLoader plugins for the one
> that matches the current process, and installs the one that matches.  Then
> that plugin has the job of filling in the section load list.  In your case,
> that would just be to copy all the section addresses directly to the section
> load map.
> 
>> More generally, how does lldb figure out where symbols are in an arbitrary
> target when the use mode is attach, as opposed to launching the process
> (therefore learning the layout).
> 
> That's handled the same way as launch.  When you attach, lldb gets host info
> from the other side of the connection (you can also help this out by
> providing an appropriate triple when you create the target before
> attaching).  It uses that to figure out which DynamicLoader plugin to use.
> And again, it's the DynamicLoader's job to look at the memory of the target
> process and figure out where the images got mapped.  How it does that is
> magic specific to each plugin.
> 
> JIm
> 
> 
>> 
>> Adrian
>> 
>> 
>> 
>>> On Nov 8, 2018, at 11:36 AM, Jim Ingham  wrote:
>>> 
>>> lldb finds the symbol you asked for in the elf file's symbols, and makes
> a "location" for that address in that binary (as a section-relative
> address).  But that won't help it actually SET the breakpoint, since that
> doesn't tell us where that section will end up in the executable image when
> it runs.  It is the job of the DynamicLoader plugin for whatever platform
> you are debugging to observe a process as it is getting launched and
> register where all the sections land memory.  The section load map is the
> storage for this information.  If that isn't getting filled in then we won't
> be able to actually set the breakpoint in the target.  It sounds like the
> Dynamic Loader step is missing.
>>> 
>>> Jim
>>> 
>>> 
 On Nov 8, 2018, at 10:20 AM, Adrian Harris via lldb-dev
>  wrote:
 
 (lldb) file tile.elf
 Current executable set to 'tile.elf' (cs).
 (lldb) b main
 lldb Target::AddBreakpoint (internal = no) => break_id = 1:
> name = 'main'
 
 
 lldb Added location: 1.1: 
 module = tile.elf
 compile unit = token_pass.c
 function = main
 location = token_pass.c:74
 address = tile.elf[0x0410]
 resolved = false
 hit count = 0   
 
 
 Breakpoint 1: where = tile.elf`main + 16 at token_pass.c:74, address 
 = 0x0410
 (lldb) gdb-remote server4:33722
 Process 1 stopped
 * thread #1, stop reason = signal SIGTRAP  frame #0: 0x0422
 tile.elf`main:
 tile.elf[0x422] <+34>: eq16   r5, 0
 tile.elf[0x424] <+36>: addc16 r0 = r7, 0
 tile.elf[0x428] <+40>: eq16   r0, r7
 tile.elf[0x42a] <+42>: jc 0xb
 (lldb) break list
 Current breakpoints:
 1: name = 'main', locations = 1
 1.1: where = tile.elf`main + 16 at token_pass.c:74, address = 
 tile.elf[0x0410], unresolved, hit count = 0
 
 So it is still not resolved.
 
 Adrian
 
 
> On Nov 8, 2018, at 11:06 AM, ted.woodw...@codeaurora.org wrote:
> 
> What happens if you do this:
> 
> (lldb) file tile.elf
> (lldb) b main
> (lldb) gdb-remote 
> 
> ?
> 
> --
> Ted Woodward
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
> 
> -Original Message-
> From: lldb-dev  On Behalf Of 
> Adrian Harris via lldb-dev
> Sent: Thursday, November 8, 2018 11:09 AM
> To: via lldb-dev 
> Subject: [lldb-dev] problem resolving symbolic breakpoint on a 
> remote target
> 
> Hi Everyone,
> 
> I'm unab

Re: [lldb-dev] [llvm-dev] Updates on SVN to GitHub migration

[James Y Knight via lldb-dev]

It'd be nice to know what about our repository is breaking it. Do they have
any idea what that is?

For example -- I think that we probably will want to archive+discard many
of the random branches and tags currently in the repository. If the large
number of branches and tags is breaking it, then maybe it just starts
working after we do so.

On Thu, Nov 8, 2018 at 3:53 PM Anton Korobeynikov 
wrote:

> Some status update wrt GitHub SVN bridge.
>
> It does not work for any non-trivial (= LLVM) repo. I filled the issue
> there, however, there is no ETA when it will be fixed. Even worse,
> there are no promises that the issue will be addressed at all. Though
> they are aware that this is the issue for us.
> On Thu, Nov 8, 2018 at 12:53 PM Nico Weber via llvm-dev
>  wrote:
> >
> > What's the status here?
> >
> > Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html
> updated with the current status of things?
> >
> > And once things are usable, probably update
> https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
> as well.
> >
> > On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> On 2018-10-24 08:25, Whisperity via cfe-dev wrote:
> >> > They are not shown in the project graph, but if you open the "branch"
> >> > drop down it has a tab named 'Tags'.
> >>
> >> It shows some tags there, but not all of them. But clicking "releases"
> >> then "Tags" will show this page [1], which seems to include all of them.
> >>
> >> [1] https://github.com/llvm-git-prototype/llvm/tags
> >>
> >> --
> >> /Jacob Carlborg
> >>
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> > ___
> > LLVM Developers mailing list
> > llvm-...@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Updates on SVN to GitHub migration

[Anton Korobeynikov via lldb-dev]

No idea, the checkout just timed out. I tried to play with sparse
checkouts, etc. and my current hypothesis that the large number of
revisions makes it unhappy.
On Fri, Nov 9, 2018 at 2:39 AM James Y Knight  wrote:
>
> It'd be nice to know what about our repository is breaking it. Do they have 
> any idea what that is?
>
> For example -- I think that we probably will want to archive+discard many of 
> the random branches and tags currently in the repository. If the large number 
> of branches and tags is breaking it, then maybe it just starts working after 
> we do so.
>
> On Thu, Nov 8, 2018 at 3:53 PM Anton Korobeynikov  
> wrote:
>>
>> Some status update wrt GitHub SVN bridge.
>>
>> It does not work for any non-trivial (= LLVM) repo. I filled the issue
>> there, however, there is no ETA when it will be fixed. Even worse,
>> there are no promises that the issue will be addressed at all. Though
>> they are aware that this is the issue for us.
>> On Thu, Nov 8, 2018 at 12:53 PM Nico Weber via llvm-dev
>>  wrote:
>> >
>> > What's the status here?
>> >
>> > Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html updated 
>> > with the current status of things?
>> >
>> > And once things are usable, probably update 
>> > https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
>> >  as well.
>> >
>> > On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev 
>> >  wrote:
>> >>
>> >> On 2018-10-24 08:25, Whisperity via cfe-dev wrote:
>> >> > They are not shown in the project graph, but if you open the "branch"
>> >> > drop down it has a tab named 'Tags'.
>> >>
>> >> It shows some tags there, but not all of them. But clicking "releases"
>> >> then "Tags" will show this page [1], which seems to include all of them.
>> >>
>> >> [1] https://github.com/llvm-git-prototype/llvm/tags
>> >>
>> >> --
>> >> /Jacob Carlborg
>> >>
>> >> ___
>> >> lldb-dev mailing list
>> >> lldb-dev@lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>> > ___
>> > LLVM Developers mailing list
>> > llvm-...@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>> --
>> With best regards, Anton Korobeynikov
>> Department of Statistical Modelling, Saint Petersburg State University



--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev