date:20160322

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

2016-03-22 Thread Ted Woodward via lldb-dev


This is the code in DynamicLoaderHexagonDYLD.cpp that is loading sections, with 
my change to call GetLoadBaseAddress():

for (unsigned i = 0; i < num_sections; ++i)
{
SectionSP section_sp (sections->GetSectionAtIndex(i));
lldb::addr_t new_load_addr = section_sp->GetFileAddress() + base_addr;

if (section_sp->GetLoadBaseAddress(&target) == LLDB_INVALID_ADDRESS)
target.SetSectionLoadAddress(section_sp, new_load_addr);
}

But section_sp->GetLoadBaseAddress() always returns LLDB_INVALID_ADDRESS, even 
when I set the slide with "target modules load -f dlopen -s 0x2" and verify 
that it's there with " image dump sections dlopen", so I'm always calling 
SetSectionLoadAddress() with the section's file address.

Ted

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


-Original Message-
From: Greg Clayton [mailto:gclay...@apple.com] 
Sent: Friday, March 18, 2016 7:34 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] "target modules load" and breakpoints not working 
correctly


> On Mar 18, 2016, at 4:37 PM, Ted Woodward  wrote:
> 
> I found why the load addresses are getting dropped. When I do "target modules 
> load", it calls SectionLoadList::SetSectionLoadAddress(), setting the new 
> load address for each section. Then when I attach, 
> DynamicLoaderHexagonDYLD::DidAttach() calls 
> DynamicLoaderHexagonDYLD::UpdateLoadedSections(), which calls 
> Target::SetSectionLoadAddress() for each section, resetting the load address 
> to the address in the relevant file.
> 
> If I remove the call to Target::SetSectionLoadAddress(), I can't hit 
> breakpoints. So I need this, but I think I should only do this if the section 
> isn't already loaded.
> 
> 
> How do I tell if a section is already loaded?

Sounds like you need to fix you DynamicLoaderHexagonDYLD right? No? Is there 
nothing in your program that you can see where things are loaded?

You can ask the section to resolve itself:


lldb::addr_t
SBSection::GetLoadAddress (lldb::SBTarget &target);

If the return value is LLDB_INVALID_ADDRESS, then the section is not loaded in 
the target.

Greg

> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
> a Linux Foundation Collaborative Project
> 
> 
> -Original Message-
> From: Greg Clayton [mailto:gclay...@apple.com]
> Sent: Friday, March 18, 2016 4:32 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
> working correctly
> 
> SectionLoadList::SetSectionLoadAddress() in SectionLoadList.cpp
> 
>> On Mar 18, 2016, at 1:54 PM, Ted Woodward  
>> wrote:
>> 
>> I don't see anything in the packet log that would cause the change. Most of 
>> the interesting packets (like qShlibInfoAddr, qProcessInfo or qHostInfo) 
>> return an empty reply.
>> 
>> Where should I set a breakpoint to see the load addresses moving?
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora 
>> Forum, a Linux Foundation Collaborative Project
>> 
>> 
>> -Original Message-
>> From: Greg Clayton [mailto:gclay...@apple.com]
>> Sent: Friday, March 18, 2016 3:12 PM
>> To: Ted Woodward 
>> Cc: LLDB 
>> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
>> working correctly
>> 
>> So you will need to find out who is sliding the shared library incorrectly. 
>> It might be a packet that is received through the GDB remote protocol, so 
>> there might be a bug in your GDB server.
>> 
>> Greg
>> 
>>> On Mar 18, 2016, at 11:45 AM, Ted Woodward  
>>> wrote:
>>> 
>>> Your guess is right - the sections moved. Before attaching:
>>> 
>>> 0x0008 code [0x0003-0x00068d5c)  
>>> 0x00011000 0x00038d5c 0x0006 dlopen..text
>>> 
>>> After attaching:
>>> 
>>> 0x0008 code [0x0001-0x00048d5c)  
>>> 0x00011000 0x00038d5c 0x0006 dlopen..text
>>> 
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora 
>>> Forum, a Linux Foundation Collaborative Project
>>> 
>>> -Original Message-
>>> From: Greg Clayton [mailto:gclay...@apple.com]
>>> Sent: Thursday, March 17, 2016 12:44 PM
>>> To: Ted Woodward 
>>> Cc: LLDB 
>>> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
>>> working correctly
>>> 
>>> Sounds like something is going wrong when resolving the address. I am 
>>> guessing that your sections got unloaded when you attached to your GDB 
>>> remote target. So try this:
>>> 
>>> (lldb) file u:\lldb_test\dlopen
>>> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
>>> (lldb) target modules load -f dlopen -s 0x2
>>> (lldb) b main
>>> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address =
>>> 0x00030018
>>> 
>>> Note we got the addres

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

2016-03-22 Thread Greg Clayton via lldb-dev


> On Mar 22, 2016, at 1:45 PM, Ted Woodward  wrote:
> 
> 
> This is the code in DynamicLoaderHexagonDYLD.cpp that is loading sections, 
> with my change to call GetLoadBaseAddress():
> 
>for (unsigned i = 0; i < num_sections; ++i)
>{
>SectionSP section_sp (sections->GetSectionAtIndex(i));
>lldb::addr_t new_load_addr = section_sp->GetFileAddress() + base_addr;
> 
>if (section_sp->GetLoadBaseAddress(&target) == LLDB_INVALID_ADDRESS)
>target.SetSectionLoadAddress(section_sp, new_load_addr);
>}
> 
> But section_sp->GetLoadBaseAddress() always returns LLDB_INVALID_ADDRESS, 
> even when I set the slide with "target modules load -f dlopen -s 0x2" and 
> verify that it's there with " image dump sections dlopen", so I'm always 
> calling SetSectionLoadAddress() with the section's file address.

Step through the code and let me know what isn't working.

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

Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert

2016-03-22 Thread Enrico Granata via lldb-dev

Ted,
I think this is fixed by r264096

Can you try and make sure it works for you?

> On Mar 21, 2016, at 2:51 PM, Enrico Granata via lldb-dev 
>  wrote:
> 
> 
>> On Mar 21, 2016, at 2:27 PM, via lldb-dev > > wrote:
>> 
>> Bug ID   27020 
>> Summary  "command alias r run" causes an assert   
>> Product  lldb
>> Version  unspecified
>> Hardware PC
>> OS   Windows NT
>> Status   NEW
>> Severity normal
>> Priority P
>> ComponentAll Bugs
>> Assignee lldb-dev@lists.llvm.org 
>> Reporter ted.woodw...@codeaurora.org 
>> CC   llvm-b...@lists.llvm.org 
>> Classification   Unclassified
>> 
>> This happens on Linux and Windows; probably all platforms.
>> 
>> >bin/lldb /bin/ls
>> (lldb) target create "/bin/ls"
>> Current executable set to '/bin/ls' (x86_64).
>> (lldb) command alias r run
>> warning: Overwriting existing definition for 'r'.
>> (lldb) r
>> CommandAlias::Execute is not to be called
>> UNREACHABLE executed at
>> /local/scratch/ted/tip/llvm/tools/lldb/source/Interpreter/CommandAlias.cpp:181!
>> Abort (core dumped)
>> 
>> 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
> 
> Ted,
> unfortunately I am more than a little busy at the moment - and it would 
> probably be a day or two before I can actually take a meaningful look at this
> 
> On the other hand, I suspect I know what the issue you’re running into is
> 
> Due to existing complexity in the interpreter, a CommandAlias isn’t directly 
> executable. So, we have CommandInterpreter::BuildAliasResult() which is the 
> function that is responsible for taking an alias apart and passing the pieces 
> to the command interpreter for actual execution.
> In your case, what is happening is that you have an alias to an alias, so the 
> underlying command is actually an alias
> 
> What one would need to try and do is write a recursive function that, given 
> an alias, potentially nested, spits out the final OptionArgVectorSP and 
> non-alias CommandObject
> It is something I can work on, but as I said, it’s going to be a few days 
> before I can get to it. So, if you want to try your hand at a patch to this 
> effect, I would be most happy to take a look at it
> 
> Apologies for the breakage and thanks for reporting this
> 
> - Enrico
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert

2016-03-22 Thread Ted Woodward via lldb-dev

The assert is gone – the alias to an alias behaves as expected.

 

There is one issue with my testcase, “command alias r run”. That’s “help r”. 
The last line is “'r' is an abbreviation for 'run -c /bin/sh --'”, but that’s 
not true. ‘run’ is an abbreviation for 'process launch -c /bin/sh --', and r is 
an abbreviation for ‘run’. From that help you’d infer that ‘r’ was an 
abbreviation for ‘process launch –c /bin/sh -- -c /bin/sh’.

 

Thanks for the quick fix!

 

Ted

--

Qualcomm Innovation Center, Inc.

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

 

From: egran...@apple.com [mailto:egran...@apple.com] 
Sent: Tuesday, March 22, 2016 4:14 PM
To: Ted Woodward 
Cc: LLDB 
Subject: Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert

 

Ted,

I think this is fixed by r264096

 

Can you try and make sure it works for you?

 

On Mar 21, 2016, at 2:51 PM, Enrico Granata via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

 

 

On Mar 21, 2016, at 2:27 PM, via lldb-dev mailto:lldb-dev@lists.llvm.org> > wrote:

 


Bug ID

27020   


Summary

"command alias r run" causes an assert 


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

ted.woodw...@codeaurora.org   


CC

llvm-b...@lists.llvm.org   


Classification

Unclassified 

 

This happens on Linux and Windows; probably all platforms.
 
>bin/lldb /bin/ls
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) command alias r run
warning: Overwriting existing definition for 'r'.
(lldb) r
CommandAlias::Execute is not to be called
UNREACHABLE executed at
/local/scratch/ted/tip/llvm/tools/lldb/source/Interpreter/CommandAlias.cpp:181!
Abort (core dumped)

 

  _  

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

 

Ted,

unfortunately I am more than a little busy at the moment - and it would 
probably be a day or two before I can actually take a meaningful look at this

 

On the other hand, I suspect I know what the issue you’re running into is

 

Due to existing complexity in the interpreter, a CommandAlias isn’t directly 
executable. So, we have CommandInterpreter::BuildAliasResult() which is the 
function that is responsible for taking an alias apart and passing the pieces 
to the command interpreter for actual execution.

In your case, what is happening is that you have an alias to an alias, so the 
underlying command is actually an alias

 

What one would need to try and do is write a recursive function that, given an 
alias, potentially nested, spits out the final OptionArgVectorSP and non-alias 
CommandObject

It is something I can work on, but as I said, it’s going to be a few days 
before I can get to it. So, if you want to try your hand at a patch to this 
effect, I would be most happy to take a look at it

 

Apologies for the breakage and thanks for reporting this

 

- Enrico

 

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

 


Thanks,

- Enrico
📩 egranata@.com ☎️ 27683

 

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

Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert

2016-03-22 Thread Enrico Granata via lldb-dev


> On Mar 22, 2016, at 3:26 PM, Ted Woodward  wrote:
> 
> The assert is gone – the alias to an alias behaves as expected.

Glad to hear! I put in a test case just to make sure we don’t regress on this 
in the future

>  
> There is one issue with my testcase, “command alias r run”. That’s “help r”. 
> The last line is “'r' is an abbreviation for 'run -c /bin/sh --'”, but that’s 
> not true. ‘run’ is an abbreviation for 'process launch -c /bin/sh --', and r 
> is an abbreviation for ‘run’. From that help you’d infer that ‘r’ was an 
> abbreviation for ‘process launch –c /bin/sh -- -c /bin/sh’.
>  

I am not seeing that one - for me it just says 'r' is an abbreviation for ‘run'
With that said, I did make another patch following the one that fixes your issue
I’ll keep an eye out for this kind of issue!

> Thanks for the quick fix!

You’re welcome!
And obviously thanks to you for finding these issues out!

>  
> Ted
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> From: egran...@apple.com [mailto:egran...@apple.com] 
> Sent: Tuesday, March 22, 2016 4:14 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an 
> assert
>  
> Ted,
> I think this is fixed by r264096
>  
> Can you try and make sure it works for you?
>  
>> On Mar 21, 2016, at 2:51 PM, Enrico Granata via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>  
>>  
>>> On Mar 21, 2016, at 2:27 PM, via lldb-dev >> > wrote:
>>>  
>>> Bug ID
>>> 27020 
>>> Summary
>>> "command alias r run" causes an assert 
>>> 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
>>> ted.woodw...@codeaurora.org 
>>> CC
>>> llvm-b...@lists.llvm.org 
>>> Classification
>>> Unclassified 
>>>  
>>> This happens on Linux and Windows; probably all platforms.
>>>  
>>> >bin/lldb /bin/ls
>>> (lldb) target create "/bin/ls"
>>> Current executable set to '/bin/ls' (x86_64).
>>> (lldb) command alias r run
>>> warning: Overwriting existing definition for 'r'.
>>> (lldb) r
>>> CommandAlias::Execute is not to be called
>>> UNREACHABLE executed at
>>> /local/scratch/ted/tip/llvm/tools/lldb/source/Interpreter/CommandAlias.cpp:181!
>>> Abort (core dumped)
>>>  
>>> 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 
>>> 
>>  
>> Ted,
>> unfortunately I am more than a little busy at the moment - and it would 
>> probably be a day or two before I can actually take a meaningful look at this
>>  
>> On the other hand, I suspect I know what the issue you’re running into is
>>  
>> Due to existing complexity in the interpreter, a CommandAlias isn’t directly 
>> executable. So, we have CommandInterpreter::BuildAliasResult() which is the 
>> function that is responsible for taking an alias apart and passing the 
>> pieces to the command interpreter for actual execution.
>> In your case, what is happening is that you have an alias to an alias, so 
>> the underlying command is actually an alias
>>  
>> What one would need to try and do is write a recursive function that, given 
>> an alias, potentially nested, spits out the final OptionArgVectorSP and 
>> non-alias CommandObject
>> It is something I can work on, but as I said, it’s going to be a few days 
>> before I can get to it. So, if you want to try your hand at a patch to this 
>> effect, I would be most happy to take a look at it
>>  
>> Apologies for the breakage and thanks for reporting this
>>  
>> - Enrico
>>  
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> 
>  
> 
> Thanks,
> - Enrico
> 📩 egranata@.com  ☎️ 27683


Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

Re: [lldb-dev] "target modules load" and breakpoints not working correctly

Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert

Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert

Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert

5 matches

Site Navigation

Mail list logo

Footer information