Re: [lldb-dev] Break setting aliases...

[Pavel Labath via lldb-dev]

I use "b" for file+line breakpoints and "br set -n" for function
breakpoints, mainly because I couldn't be bothered to figure out how
that works with the "b" command. Now that I have studied the command
once again, I may try using it for function breakpoints as well...

I don't have any hard objections to new aliases (if "b" for name
breakpoints doesn't pan out, I may start using "bn" as a shorthand for
"br set -n"), though I do find the idea of beefing up the "b" command
more appealing.

On 22/07/2020 00:03, Jim Ingham via lldb-dev wrote:
> 
> 
>> On Jul 21, 2020, at 2:54 PM, Greg Clayton > > wrote:
>>
>>
>>
>>> On Jul 21, 2020, at 10:22 AM, Jim Ingham via lldb-dev
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>
>>> When we were first devising commands for lldb, we tried to be really
>>> parsimonious with the one & two letter unique command strings that
>>> lldb ships with by default.  I was trying to leave us as much
>>> flexibility as possible as we evolved, and I also wanted to make sure
>>> we weren’t taking up all the convenient short commands, leaving a
>>> cramped space for user aliases.
>>>
>>> The _regex_break command was added (and aliased by default to ‘b’) as
>>> a way to allow quick access for various common breakpoint setting
>>> options.  However it suffers from the problem that you can only
>>> provide the options that are recognized by the _regexp_break command
>>> aliases.  For instance, you can’t add the -h option to make a
>>> hardware breakpoint.  Because the “_regex_break command works by
>>> passing the command through a series of regex’s stopping at the first
>>> match, trying to extend the regular expressions to also include
>>> “anything else” while not causing one regex to claim a command that
>>> was really meant for a regex further on in the series is really tricky.
>>>
>>> That makes it kind of a wall for people.  As soon as you need to do
>>> anything it doesn’t support you have to go to a command that is not
>>> known to you (since “b” isn’t related to “break set” in any way that
>>> a normal user can actually see.)
>>>
>>> However, lldb has been around for a while and we only have two unique
>>> commands of the form “b[A-Za-z]” in the current lldb command set (br
>>> and bt).  So I think it would be okay for us to take up a few more
>>> second letter commands to make setting breakpoints more convenient.
>>>  I think adding:
>>>
>>> bs (break source) -> break set -y
>>
>> Is -y a new option you would add? I don't see it. We have --file and
>> --line
> 
> Added it yesterday.
> 
>>
>>> ba (break address) -> break set -a
>>> bn (break name) -> break set -n
>>>
>>> would provide a convenient way to set the most common classes of
>>> breakpoints while not precluding access to all the other options
>>> available to “break set”.  We could still leave “b” by itself for the
>>> _regex_break command - people who’ve figured out it’s intricacies
>>> shouldn’t lose their investment.  This would be purely additive.
>>>
>>> What do people think?
>>
>> Can we modify the _regex_break to accept options at the start or end
>> of the command somehow? 
>>
> 
> When the principle of so much of the rest of the lldb command line is
> that this sort of positional ordering is NOT necessary, doing this would
> be a shame.  At that point, I think Jonas suggestion of having a command
>  “break break-spec-set” or whatever, that took the breakpoint modify
> option group and then a specifier as an argument(s) which get parsed in
> the same way that “_regexp_break” does would be a better long-term
> supportable option.


Couldn't we have "b" command work the same way as the "expr" command? If
the user passes no arguments then he can just do "b whatever". And if he
also wants to add any parameters then he can do "b --hardware -- whatever".

The "--" is slightly unfortunate, but it's at least consistent with our
other commands taking raw input. We could avoid that by making the
command not take raw input. I think most of the "modes" of the "b"
command wouldn't need quoting in most circumstances -- source regex and
"lib`func" modes being exceptions.

On 21/07/2020 20:13, Jonas Devlieghere via lldb-dev wrote:
>  Furthermore, with a first-class command we can do a better job on the
help front which is really underwhelming for _regexp_break command aliases.

FWIW, this is the first time that I looked at the help for the "b"
command, and I have to say I found it more understandable than the "br
set" command. :P

"br set" help starts with a long list command switches, which are
supposed to show which options can be used together. I think this sort
of listing is nice when the command has a couple of modes and a few
switches, but it really misses the mark when it ends up listing 11 modes
with approximately 20 switches in each one.

This is then followed by descriptions of the 20 or so switches. This
list is alphabetical, which means the most commonly used options end up
burried between the

Re: [lldb-dev] [Release-testers] LLVM 10.0.1-final has been tagged

[Hans Wennborg via lldb-dev]

Windows is ready:

$ sha256sum LLVM-10.0.1-win*.exe
5d92025d246615b92b3fcf5661ebd2866f5668c065456066f2622933ca741b64
LLVM-10.0.1-win32.exe
126885205403490754a2555659ae52d792eedc8bb2091c09a952eac8642feb80
LLVM-10.0.1-win64.exe

It was built with the attached batch file.

On Tue, Jul 21, 2020 at 7:25 AM Tom Stellard via Release-testers
 wrote:
>
> Hi,
>
> I've tagged 10.0.1-final.  Testers, please begin uploading your binaries.
>
> Thanks,
> Tom
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers


build_llvm_1001-final._bat_
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] LLVM 10.0.1-final has been tagged

[Ahsan Saghir via lldb-dev]

Hi,

I have finished testing llvm-10.0.1-final on Power PC 64bit Little Endian
Red Hat 7.4 machine and have uploaded the binary from IBM.
The sha1 file is attached.

Thanks,
Ahsan Saghir.

On Tue, 21 Jul 2020 at 01:25, Tom Stellard via Release-testers <
release-test...@lists.llvm.org> wrote:

> Hi,
>
> I've tagged 10.0.1-final.  Testers, please begin uploading your binaries.
>
> Thanks,
> Tom
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>


clang+llvm-10.0.1-powerpc64le-linux-rhel-7.4.sha1
Description: Binary data
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Remote debug arm bare metal target with lldb - load executable to target

[via lldb-dev]

Hello,

we are trying to debug firmware running on a stm32 using OpenOCD and LLDB.
GNU-GDB provides a 'load' command to load the sections from an ELF file to
the target device.
We have tried to use 'target modules load --load' command to load ELF
sections to a specific address, but that didn't work.
If there is a way at all, what is the proper way to load the executable to
the target device with LLDB?

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

Re: [lldb-dev] [Release-testers] LLVM 10.0.1-final has been tagged

[Dimitry Andric via lldb-dev]

On 21 Jul 2020, at 07:25, Tom Stellard via Release-testers 
 wrote:
> 
> I've tagged 10.0.1-final.  Testers, please begin uploading your binaries.

For the final build, I used four patches, which are attached. (Yes, I am
slowly, very slowly, working on getting these into the tree. :)

Main results on amd64-freebsd11:

  Expected Passes: 67938  (rc4: 67554)
  Passes With Retry  : 0  (rc4: 1)
  Expected Failures  :   265  (rc4:   265)
  Unsupported Tests  :  4654  (rc4:  5114)
  Unexpected Passes  : 5  (rc4: 2)
  Unexpected Failures:   541  (rc4:   513)
  Individual Timeouts:19  (rc4:11)

Test suite results on amd64-freebsd11:

  Expected Passes:  2398  (rc4:  2398)
  Unexpected Failures: 3  (rc4: 3)

Main results on i386-freebsd11:

  Expected Passes: 64993  (rc4: 64619)
  Passes With Retry  : 0  (rc4: 1)
  Expected Failures  :   248  (rc4:   248)
  Unsupported Tests  :  3083  (rc4:  3541)
  Unresolved Tests   : 1  (rc4: 0)
  Unexpected Passes  : 5  (rc4: 1)
  Unexpected Failures:   231  (rc4:   192)
  Individual Timeouts:11  (rc4: 7)

Uploaded:
SHA256 (clang+llvm-10.0.1-amd64-unknown-freebsd11.tar.xz) = 
290897c328f75df041d1abda6e25a50c2e6a0a3d939b5069661bb966bf7ac843
SHA256 (clang+llvm-10.0.1-i386-unknown-freebsd11.tar.xz) = 
f404976ad92cf846b7915cd43cd251e090a5e7524809ab96f5a65216988b2b26

-Dimitry


fix-clang-1.diff
Description: Binary data


fix-compiler-rt-1.diff
Description: Binary data


fix-libcxx-1.diff
Description: Binary data


fix-test-suite-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Break setting aliases...

[Dave Lee via lldb-dev]

On Tuesday, July 21, 2020, Jim Ingham via lldb-dev 
wrote:

> I think adding:
>
> bs (break source) -> break set -y
> ba (break address) -> break set -a
> bn (break name) -> break set -n
>
> would provide a convenient way to set the most common classes of
> breakpoints while not precluding access to all the other options available
> to “break set”.
>

If these are defined as regular aliases, I wonder how many people would
try, say, `bn -H whatever` and be confused when it doesn't work because it
didn't do the right thing (such as creating a breakpoint named "-H" in this
example). Should these new aliases support flags before and after the
positional argument? Personally I think so. But to support that, it seems
they'd need to be implemented with `command regex`. In that case, would it
be good to add similar before/after flag composition abilities to `b` as
Greg Clayton suggested?

It hasn't been mentioned in this thread, but `b` has undocumented handling
for flags: the prefix `b -` is expanded to `breakpoint set -`. Because of
this I almost never use `breakpoint set` directly. For whatever it's worth,
this means `bn` can be achieved as `b -n`, etc. As Pavel Labath suggested,
I think it's worth updating the help documentation for `b` to explicitly
lead users from `b` to `breakpoint set`.

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

Re: [lldb-dev] Break setting aliases...

[Jim Ingham via lldb-dev]

> On Jul 22, 2020, at 9:57 AM, Dave Lee  wrote:
> 
> On Tuesday, July 21, 2020, Jim Ingham via lldb-dev  > wrote:
> I think adding:
> 
> bs (break source) -> break set -y
> ba (break address) -> break set -a
> bn (break name) -> break set -n
> 
> would provide a convenient way to set the most common classes of breakpoints 
> while not precluding access to all the other options available to “break 
> set”. 
> 
> If these are defined as regular aliases, I wonder how many people would try, 
> say, `bn -H whatever` and be confused when it doesn't work because it didn't 
> do the right thing (such as creating a breakpoint named "-H" in this 
> example). Should these new aliases support flags before and after the 
> positional argument? Personally I think so. But to support that, it seems 
> they'd need to be implemented with `command regex`. In that case, would it be 
> good to add similar before/after flag composition abilities to `b` as Greg 
> Clayton suggested?

Grrr…  Apparently command aliases don’t work quite how I intended them to.  I 
thought the intent was that:

(lldb) command alias breakpoint set -y %1

would put the first argument into the %1 position, not the first command word.  
That way you could preserve the position independence of options.  But that’s 
not what it does.  %1 is just the first command word (-H in your example).

The way it works now, mine is not a useful suggestion.  When I have some time 
I’ll play around with how to make that work, until then we can keep discussing 
the _regex_break command, but the aliases I started out with are unappealing.

Jim


> 
> It hasn't been mentioned in this thread, but `b` has undocumented handling 
> for flags: the prefix `b -` is expanded to `breakpoint set -`. Because of 
> this I almost never use `breakpoint set` directly. For whatever it's worth, 
> this means `bn` can be achieved as `b -n`, etc. As Pavel Labath suggested, I 
> think it's worth updating the help documentation for `b` to explicitly lead 
> users from `b` to `breakpoint set`.
> 
> Dave

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

Re: [lldb-dev] Break setting aliases...

[Jim Ingham via lldb-dev]

> On Jul 22, 2020, at 12:34 AM, Pavel Labath  wrote:
> 
> I use "b" for file+line breakpoints and "br set -n" for function
> breakpoints, mainly because I couldn't be bothered to figure out how
> that works with the "b" command. Now that I have studied the command
> once again, I may try using it for function breakpoints as well...
> 
> I don't have any hard objections to new aliases (if "b" for name
> breakpoints doesn't pan out, I may start using "bn" as a shorthand for
> "br set -n"), though I do find the idea of beefing up the "b" command
> more appealing.
> 
> On 22/07/2020 00:03, Jim Ingham via lldb-dev wrote:
>> 
>> 
>>> On Jul 21, 2020, at 2:54 PM, Greg Clayton >> > wrote:
>>> 
>>> 
>>> 
 On Jul 21, 2020, at 10:22 AM, Jim Ingham via lldb-dev
 mailto:lldb-dev@lists.llvm.org>> wrote:
 
 When we were first devising commands for lldb, we tried to be really
 parsimonious with the one & two letter unique command strings that
 lldb ships with by default.  I was trying to leave us as much
 flexibility as possible as we evolved, and I also wanted to make sure
 we weren’t taking up all the convenient short commands, leaving a
 cramped space for user aliases.
 
 The _regex_break command was added (and aliased by default to ‘b’) as
 a way to allow quick access for various common breakpoint setting
 options.  However it suffers from the problem that you can only
 provide the options that are recognized by the _regexp_break command
 aliases.  For instance, you can’t add the -h option to make a
 hardware breakpoint.  Because the “_regex_break command works by
 passing the command through a series of regex’s stopping at the first
 match, trying to extend the regular expressions to also include
 “anything else” while not causing one regex to claim a command that
 was really meant for a regex further on in the series is really tricky.
 
 That makes it kind of a wall for people.  As soon as you need to do
 anything it doesn’t support you have to go to a command that is not
 known to you (since “b” isn’t related to “break set” in any way that
 a normal user can actually see.)
 
 However, lldb has been around for a while and we only have two unique
 commands of the form “b[A-Za-z]” in the current lldb command set (br
 and bt).  So I think it would be okay for us to take up a few more
 second letter commands to make setting breakpoints more convenient.
  I think adding:
 
 bs (break source) -> break set -y
>>> 
>>> Is -y a new option you would add? I don't see it. We have --file and
>>> --line
>> 
>> Added it yesterday.
>> 
>>> 
 ba (break address) -> break set -a
 bn (break name) -> break set -n
 
 would provide a convenient way to set the most common classes of
 breakpoints while not precluding access to all the other options
 available to “break set”.  We could still leave “b” by itself for the
 _regex_break command - people who’ve figured out it’s intricacies
 shouldn’t lose their investment.  This would be purely additive.
 
 What do people think?
>>> 
>>> Can we modify the _regex_break to accept options at the start or end
>>> of the command somehow? 
>>> 
>> 
>> When the principle of so much of the rest of the lldb command line is
>> that this sort of positional ordering is NOT necessary, doing this would
>> be a shame.  At that point, I think Jonas suggestion of having a command
>>  “break break-spec-set” or whatever, that took the breakpoint modify
>> option group and then a specifier as an argument(s) which get parsed in
>> the same way that “_regexp_break” does would be a better long-term
>> supportable option.
> 
> 
> Couldn't we have "b" command work the same way as the "expr" command? If
> the user passes no arguments then he can just do "b whatever". And if he
> also wants to add any parameters then he can do "b --hardware -- whatever".
> 
> The "--" is slightly unfortunate, but it's at least consistent with our
> other commands taking raw input. We could avoid that by making the
> command not take raw input. I think most of the "modes" of the "b"
> command wouldn't need quoting in most circumstances -- source regex and
> "lib`func" modes being exceptions.

If anybody wants to work on this, I think Jonas is right, the first step would 
be to convert it to an actual command not a regex command.  The _regexp-break 
command is already hard enough to comprehend.

You could still do the actual specifier parsing with a series of regex’s if 
that seems best, though there might be easier ways to do it.  I also don’t 
think this would need to be a raw command, rather it could be a parsed command 
with one argument which was the breakpoint specifier and then all the other 
breakpoint flags.  

All the specifications you can currently pass to b are single words w/o spaces 
in them, or if they do have spaces they are th

Re: [lldb-dev] Break setting aliases...

[Greg Clayton via lldb-dev]

BTW: to see what things expand to after reach regex alias, just set this 
setting first:

(lldb) settings set interpreter.expand-regex-aliases true

Each time you type "b main" it will show you the expansion:

(lldb) b main
breakpoint set --name 'main'
...
(lldb) b main.cpp:12
breakpoint set --file 'main.cpp' --line 12
...

It shows the full expansion.

Greg

> On Jul 22, 2020, at 12:34 AM, Pavel Labath  wrote:
> 
> I use "b" for file+line breakpoints and "br set -n" for function
> breakpoints, mainly because I couldn't be bothered to figure out how
> that works with the "b" command. Now that I have studied the command
> once again, I may try using it for function breakpoints as well...
> 
> I don't have any hard objections to new aliases (if "b" for name
> breakpoints doesn't pan out, I may start using "bn" as a shorthand for
> "br set -n"), though I do find the idea of beefing up the "b" command
> more appealing.
> 
> On 22/07/2020 00:03, Jim Ingham via lldb-dev wrote:
>> 
>> 
>>> On Jul 21, 2020, at 2:54 PM, Greg Clayton >> > wrote:
>>> 
>>> 
>>> 
 On Jul 21, 2020, at 10:22 AM, Jim Ingham via lldb-dev
 mailto:lldb-dev@lists.llvm.org>> wrote:
 
 When we were first devising commands for lldb, we tried to be really
 parsimonious with the one & two letter unique command strings that
 lldb ships with by default.  I was trying to leave us as much
 flexibility as possible as we evolved, and I also wanted to make sure
 we weren’t taking up all the convenient short commands, leaving a
 cramped space for user aliases.
 
 The _regex_break command was added (and aliased by default to ‘b’) as
 a way to allow quick access for various common breakpoint setting
 options.  However it suffers from the problem that you can only
 provide the options that are recognized by the _regexp_break command
 aliases.  For instance, you can’t add the -h option to make a
 hardware breakpoint.  Because the “_regex_break command works by
 passing the command through a series of regex’s stopping at the first
 match, trying to extend the regular expressions to also include
 “anything else” while not causing one regex to claim a command that
 was really meant for a regex further on in the series is really tricky.
 
 That makes it kind of a wall for people.  As soon as you need to do
 anything it doesn’t support you have to go to a command that is not
 known to you (since “b” isn’t related to “break set” in any way that
 a normal user can actually see.)
 
 However, lldb has been around for a while and we only have two unique
 commands of the form “b[A-Za-z]” in the current lldb command set (br
 and bt).  So I think it would be okay for us to take up a few more
 second letter commands to make setting breakpoints more convenient.
  I think adding:
 
 bs (break source) -> break set -y
>>> 
>>> Is -y a new option you would add? I don't see it. We have --file and
>>> --line
>> 
>> Added it yesterday.
>> 
>>> 
 ba (break address) -> break set -a
 bn (break name) -> break set -n
 
 would provide a convenient way to set the most common classes of
 breakpoints while not precluding access to all the other options
 available to “break set”.  We could still leave “b” by itself for the
 _regex_break command - people who’ve figured out it’s intricacies
 shouldn’t lose their investment.  This would be purely additive.
 
 What do people think?
>>> 
>>> Can we modify the _regex_break to accept options at the start or end
>>> of the command somehow? 
>>> 
>> 
>> When the principle of so much of the rest of the lldb command line is
>> that this sort of positional ordering is NOT necessary, doing this would
>> be a shame.  At that point, I think Jonas suggestion of having a command
>>  “break break-spec-set” or whatever, that took the breakpoint modify
>> option group and then a specifier as an argument(s) which get parsed in
>> the same way that “_regexp_break” does would be a better long-term
>> supportable option.
> 
> 
> Couldn't we have "b" command work the same way as the "expr" command? If
> the user passes no arguments then he can just do "b whatever". And if he
> also wants to add any parameters then he can do "b --hardware -- whatever".
> 
> The "--" is slightly unfortunate, but it's at least consistent with our
> other commands taking raw input. We could avoid that by making the
> command not take raw input. I think most of the "modes" of the "b"
> command wouldn't need quoting in most circumstances -- source regex and
> "lib`func" modes being exceptions.
> 
> On 21/07/2020 20:13, Jonas Devlieghere via lldb-dev wrote:
>> Furthermore, with a first-class command we can do a better job on the
> help front which is really underwhelming for _regexp_break command aliases.
> 
> FWIW, this is the first time that I looked at the help for the "b"
> command, and I 

Re: [lldb-dev] Remote debug arm bare metal target with lldb - load executable to target

[Greg Clayton via lldb-dev]

The --load option should work if all of the program headers have the right 
addresses. LLDB should try to load all PT_LOAD program headers into memory at 
the address that they are loaded at.

Is this a baseboard situation where you have an ELF file that has program 
headers with all of the correct load addresses? If so, you want to make sure 
that you specify no OS and no vendor when loading your target:

(lldb) target create --arch armv7-none-none

Why? Because when LLDB knows where is no OS and no vendor then it will select 
the right dynamic loader plug-in. This plug-in will automatically set the 
"load" address for all program headers to match the "file" address found in the 
ELF file. If LLDB believes you have an OS that you are running on, it will try 
and load a dynamic loader plugin that will wait until that plugin detects that 
your executable has been dynamically loaded and try to set the "load" address 
intelligently.

LLDB has the notion of "load" and "file" addresses. "file" addresses are 
addresses as they are found in each executable or shared library object file 
(ELF, mach-o, COFF, etc) that exists in your target. Once your program is 
running, the dynamic loader will try and determine the "load" address for each 
section within each executable using the dynamic loader plug-in. Dynamic loader 
plug-ins are loaded based off of the target triple in your target.

If your ELF file has the entry point correctly set, you can use the 
"--set-pc-to-entry" option.

So if you have a static ELF file where all addresses are correct, you can 
probably use:

(lldb) target create --arch armv7-none-none a.out
(lldb) target modules load --file a.out --load --set-pc-to-entry

You can also set your load addresses manually using this command by specifying 
the any number of section name + section address tuples:

(lldb) target create --arch armv7-none-none a.out
(lldb) target modules load --file a.out --load --set-pc-to-entry .text 0x20 
.data 0x30



> On Jul 22, 2020, at 9:10 AM, via lldb-dev  wrote:
> 
> Hello,
> we are trying to debug firmware running on a stm32 using OpenOCD and LLDB.
> GNU-GDB provides a ‘load’ command to load the sections from an ELF file to 
> the target device.
> We have tried to use ‘target modules load --load’ command to load ELF 
> sections to a specific address, but that didn’t work.
> If there is a way at all, what is the proper way to load the executable to 
> the target device with LLDB?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
> 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev