[lldb-dev] LLDB bare-metal and 'load' command
Hi Greg, I was trying to do some bare-metal debugging with LLDB and an ARM board. I noticed that LLDB does not have a command similar to 'load' command of GDB. Searching the mailing list, it seems that this issue has been discussed before. http://lists.llvm.org/pipermail/lldb-dev/2014-March/003476.html Has any such command been added in LLDB since that discussion? If not, then I would like to take a stab at adding this command in LLDB proper. I was wondering where such command will make most sense. Should it be added to some existing group like 'process' or 'image' or be a stand-alone command? Thanks, Abid ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB bare-metal and 'load' command
Hi Abid, How are you communicating with the ARM? lldb->gdbserver->jtag probe? We've discussed doing that kind of thing with Hexagon, but we're nowhere near implementing it. "process launch" on linux can download the target to the remote machine when connected in platform mode. If you make your remote server and platform do that, it should handle what you need. 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: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Abid, > Hafiz via lldb-dev > Sent: Friday, December 16, 2016 11:00 AM > To: Greg Clayton (gclay...@apple.com) > Cc: lldb-dev@lists.llvm.org > Subject: [lldb-dev] LLDB bare-metal and 'load' command > > Hi Greg, > I was trying to do some bare-metal debugging with LLDB and an ARM board. I > noticed that LLDB does not have a command similar to 'load' command of > GDB. Searching the mailing list, it seems that this issue has been discussed > before. > > http://lists.llvm.org/pipermail/lldb-dev/2014-March/003476.html > > Has any such command been added in LLDB since that discussion? If not, > then I would like to take a stab at adding this command in LLDB proper. I was > wondering where such command will make most sense. Should it be added > to some existing group like 'process' or 'image' or be a stand-alone > command? > > Thanks, > Abid > ___ > 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] LLDB bare-metal and 'load' command
Hi Ted, I have a utility that communicate with the board (jtag over usb) and presents a gdb-server interface. I could debug an application on the board using gdb. I was trying to do similar thing with LLDB but could not figure how to do what 'load' command of gdb does. Thanks, Abid -- Hafiz Abid Qadeer hafiz_a...@mentor.com CodeSourcery / Mentor Embedded > -Original Message- > From: Ted Woodward [mailto:ted.woodw...@codeaurora.org] > Sent: 16 December 2016 17:23 > To: Abid, Hafiz; 'Greg Clayton'; 'LLDB' > Subject: RE: [lldb-dev] LLDB bare-metal and 'load' command > > Hi Abid, > > How are you communicating with the ARM? lldb->gdbserver->jtag probe? > We've discussed doing that kind of thing with Hexagon, but we're nowhere > near implementing it. > > "process launch" on linux can download the target to the remote machine > when connected in platform mode. If you make your remote server and > platform do that, it should handle what you need. > > 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: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Abid, > > Hafiz via lldb-dev > > Sent: Friday, December 16, 2016 11:00 AM > > To: Greg Clayton (gclay...@apple.com) > > Cc: lldb-dev@lists.llvm.org > > Subject: [lldb-dev] LLDB bare-metal and 'load' command > > > > Hi Greg, > > I was trying to do some bare-metal debugging with LLDB and an ARM > board. I > > noticed that LLDB does not have a command similar to 'load' command of > > GDB. Searching the mailing list, it seems that this issue has been discussed > > before. > > > > http://lists.llvm.org/pipermail/lldb-dev/2014-March/003476.html > > > > Has any such command been added in LLDB since that discussion? If not, > > then I would like to take a stab at adding this command in LLDB proper. I > was > > wondering where such command will make most sense. Should it be added > > to some existing group like 'process' or 'image' or be a stand-alone > > command? > > > > Thanks, > > Abid > > ___ > > 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] logging in lldb
Yeah, I’m with Jason. I don’t find the current state of things hard to read or
work with.
The proposed solutions seem a little uglier to me. I try to avoid macros, to
me it makes it look like the code is shouting at you, giving the log lines more
prominence then they deserve in the overall flow of the code. And all upper
case is harder to read. If accumulating the log involves substantial code and
the code is all in macros it won’t be debuggable, which is a minor shame. But
it’s not a huge deal since you can move the the code out of the log statement
temporarily if you need to debug it.
I don’t see the need to work on this, but if it bugs you and you have the time
to do it, the moieties weigh evenly enough that I can’t see a reason to object.
Jim
> On Dec 15, 2016, at 4:01 PM, Jason Molenda wrote:
>
> Hi Pavel, sorry for not keeping up with the thread, I've been super busy all
> this week. I'm not going to object to where this proposal has ended up. I
> personally have a preference for the old system but not based on any
> justifiable reasons.
>
>
>> On Dec 15, 2016, at 7:13 AM, Pavel Labath wrote:
>>
>> Just to let you know, I will be on vacation until the end of the year,
>> so probably will not respond to any comments until January. If you
>> have any concerns, do let me know, as I'd like to get started when I
>> get back.
>>
>> pl
>>
>> On 13 December 2016 at 16:32, Pavel Labath wrote:
>>> Hello again,
>>>
>>> I'd to get back to the question of unifying llvm's and lldb's logging
>>> mechanisms that Chris asked about. In the way these two are
>>> implemented now, they have a number of similarities, but also a number
>>> of differences. Among the differences, there is one that I think will
>>> be most painful to resolve, so I'll start with that one:
>>>
>>> I am talking about how to disable logging at compile-time. Currently,
>>> llvm's logging mechanism can be controlled both at runtime and
>>> compile-time. lldb's can be only controlled at runtime. While we may
>>> not want/need the compile-time knob, it is a very hard requirement for
>>> llvm, which tries to squeeze every ounce of performance from the
>>> hardware. So, if we are going to have a common logging API, we will
>>> need to support being compiled without it.
>>>
>>> This has impact on the kind of syntax we are able to use. I see two
>>> problems here.
>>>
>>> 1. The first one is that our log patterns are split into independent
>>> parts. Currently the pattern is:
>>> Log *log = GetLogIf(Flag);
>>> ...
>>> if (log) log->Printf(...);
>>>
>>> The API we (mostly?) converged to above is:
>>> Log *log = GetLogIf(Flag);
>>> ...
>>> LLDB_LOG(log, ...);
>>>
>>> If we want to compile the logging away, getting rid of the second part
>>> is easy, as it is already a macro. However, for a completely clean
>>> compile, we would need to remove the first part as well. Since
>>> wrapping it in #ifdef would be too ugly, I think the easiest solution
>>> would be to just make it go away completely.
>>>
>>> The way I understand it, the reason we do it in two steps now is to
>>> make the code fast if logging is off. My proposal here would be to
>>> make the code very fast even without the additional local variable. If
>>> we could use the macro like:
>>> LLDB_LOG(Flag, ...)
>>> where the macro would expand to something like:
>>> if (LLVM_UNLIKELY(Flag & lldb_private::enabled_channels)) log_stuff(...)
>>> where `enabled_channels` is just a global integral variable then the
>>> overhead of a disabled log statement would be three instructions
>>> (load, and, branch), some of which could be reused if we had more
>>> logging statements in a function. Plus the macro could hint the cpu
>>> and compiler to optimize for the "false" case. This is still an
>>> increase over the status quo, where the overhead of a log statement is
>>> one or two instructions, but I am not sure if this is significant.
>>>
>>> 2. The second, and probably bigger, issue is the one mentioned by
>>> Jason earlier in this thread -- the ability to insert random code into
>>> if(log) blocks. Right writing the following is easy:
>>> if (log) {
>>> do_random_stuff();
>>> log->Printf(...);
>>> }
>>>
>>> In the first version of the macro, this is still easy to write, as we
>>> don't have to worry about compile-time. But if we need this to go
>>> away, we will need to resort to the same macro approach as llvm:
>>> LLDB_DEBUG( { do_random_stuff(); LLDB_LOG(...); });
>>> Which has all the disadvantages Jason mentioned. Although, I don't
>>> think this has to be that bad, as we probably will not be doing this
>>> very often, and the issues can be mitigated by putting the actual code
>>> in a function, and only putting the function calls inside the macro.
>>>
>>>
>>>
>>> So, my question to you is: Do you think these two drawbacks are worth
>>> sacrificing for the sake of having a unified llvm-wide logging
>>> infrastructure? I am willing to drive this, and implement
Re: [lldb-dev] LLDB bare-metal and 'load' command
> On Dec 16, 2016, at 9:00 AM, Abid, Hafiz wrote: > > Hi Greg, > I was trying to do some bare-metal debugging with LLDB and an ARM board. I > noticed that > LLDB does not have a command similar to 'load' command of GDB. Searching the > mailing list, > it seems that this issue has been discussed before. > > http://lists.llvm.org/pipermail/lldb-dev/2014-March/003476.html > > Has any such command been added in LLDB since that discussion? If not, then I > would like to > take a stab at adding this command in LLDB proper. I was wondering where such > command > will make most sense. Should it be added to some existing group like > 'process' or 'image' or > be a stand-alone command? No ELF specific loader has been written so I would go ahead and write one in python and check it into $(trunk)/examples/python as loadelf.py. I am not sure if you can add a python command as a child of an existing command, but you can call it "load-elf". There are a few open source ELF parsers in python, and I have one if you need it so that you don't have to write one from scratch. If you need any help let me know. Greg Clayton > > Thanks, > Abid ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB bare-metal and 'load' command
Original message From: Greg Clayton Date: 16/12/2016 21:48 (GMT+00:00) To: "Abid, Hafiz" Cc: lldb-dev@lists.llvm.org Subject: Re: LLDB bare-metal and 'load' command > On Dec 16, 2016, at 9:00 AM, Abid, Hafiz wrote: > > Hi Greg, > I was trying to do some bare-metal debugging with LLDB and an ARM board. I > noticed that > LLDB does not have a command similar to 'load' command of GDB. Searching the > mailing list, > it seems that this issue has been discussed before. > > http://lists.llvm.org/pipermail/lldb-dev/2014-March/003476.html > > Has any such command been added in LLDB since that discussion? If not, then I > would like to > take a stab at adding this command in LLDB proper. I was wondering where such > command > will make most sense. Should it be added to some existing group like > 'process' or 'image' or > be a stand-alone command? No ELF specific loader has been written so I would go ahead and write one in python and check it into $(trunk)/examples/python as loadelf.py. I am not sure if you can add a python command as a child of an existing command, but you can call it "load-elf". There are a few open source ELF parsers in python, and I have one if you need it so that you don't have to write one from scratch. Thanks for your comments. I was thinking of adding a normal command in C++ instead of python. Do you think that is not the right way to go about it? Thanks, Abid ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB bare-metal and 'load' command
> On Dec 16, 2016, at 2:29 PM, Abid, Hafiz wrote: > > > > Original message > From: Greg Clayton > Date: 16/12/2016 21:48 (GMT+00:00) > To: "Abid, Hafiz" > Cc: lldb-dev@lists.llvm.org > Subject: Re: LLDB bare-metal and 'load' command > > > > On Dec 16, 2016, at 9:00 AM, Abid, Hafiz wrote: > > > > Hi Greg, > > I was trying to do some bare-metal debugging with LLDB and an ARM board. I > > noticed that > > LLDB does not have a command similar to 'load' command of GDB. Searching > > the mailing list, > > it seems that this issue has been discussed before. > > > > http://lists.llvm.org/pipermail/lldb-dev/2014-March/003476.html > > > > Has any such command been added in LLDB since that discussion? If not, then > > I would like to > > take a stab at adding this command in LLDB proper. I was wondering where > > such command > > will make most sense. Should it be added to some existing group like > > 'process' or 'image' or > > be a stand-alone command? > > No ELF specific loader has been written so I would go ahead and write one in > python and check it into $(trunk)/examples/python as loadelf.py. I am not > sure if you can add a python command as a child of an existing command, but > you can call it "load-elf". There are a few open source ELF parsers in > python, and I have one if you need it so that you don't have to write one > from scratch. > > Thanks for your comments. I was thinking of adding a normal command in C++ > instead of python. Do you think that is not the right way to go about it? That is another way. You could add a few calls: Error Module::LoadInMemory(); And then ObjectFile would need: Error ObjectFile::LoadInMemory(); The question is what are the arguments going to be? I see a few options: 1 - no arguments, just load the file exactly where at the addresses in the file itself 2 - shift the entire file by some amount with a single load address argument 3 - specify where each section goes with a SectionLoadList For number 2 above, if you do specify on address, what does that mean when ELF program headers have 3 loadable chunks? Does the first address specify the address of the first chunk and all the rest are relative to it? Do you find the program header chunk with the lowest address and then load it there and all others are relative? If we specify where each section would go by supplying a SectionLoadList the main problem is that ELF loads files using the program headers and those don't correspond to any sections directly sometimes as one program header can span many sections? There might be some program headers that don't represent sections. What do we do then? For options 2 and 3 do we then need to apply relocations after loading things? I would almost vote for #1 where we just load the file where it says it wants to go. Bare board folks should be able to get the linker to emit things at the right addresses and then it works fine for us. If you do a built-in command I would vote to add some options to the existing "target modules load" command. This command already can take a slide: help target modules load Set the load addresses for one or more sections in a target module. Syntax: target modules load [--file --uuid ] [ ] Command Options Usage: target modules load [-u ] [-f ] [-s ] [ [ [...]]] -f ( --file ) Fullpath or basename for module to load. -s ( --slide ) Set the load address for all sections to be the virtual address in the file plus the offset. -u ( --uuid ) A module UUID value. This command takes options and free-form arguments. If your arguments resemble option specifiers (i.e., they start with a - or --), you must use ' -- ' between the end of the command options and the beginning of the arguments. This is currently used by specifying a file "--file " and then a section name followed by load address: (lldb) target modules load --file /tmp/a.out .text 0x1000 .data 0x2000 .bss 0x3000 Or you can specify a slide: (lldb) target modules load --file /tmp/a.out --slide 0x2 So we can modify this command by adding a "--load" option: (lldb) target modules load --file /tmp/a.out --load If there is no slide, then load it where the file where all addresses in the file exist. If there is a slide, you need to verify this is a relocatable file and then slide everything as needed. Since the arguments to this command are free form, we could pass these arguments to ObjectFile::LoadInMemory() and let each loader (ObjectFileELF and ObjectFileMach) determine what arguments are valid. Then you could do something like: (lldb) target modules load --file /tmp/a.out --load program_header[0] 0x1000 program_header[1] 0x2000 And ObjectFileELF will know what to do. Let me know what you think. Greg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailma
