[lldb-dev] Debugging ELF relocatable files using LLDB
It looks like LLDB doesn't like ELF relocatable files for debugging and asserts with the following message when tried /lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2228: unsigned int ObjectFileELF::RelocateSection(.): Assertion `false && "unexpected relocation type"' failed. Are we not supposed to debug ELF relocatable files on LLDB or am I missing something? If we cannot debug the relocatable files, is it _simply_ because those files lack program headers (program memory map) and relocations are yet to be processed (for debug info) or there are other reasons? For our target, the assembler output itself is a self contained ELF and hence will not have external references (both code and data). I am wondering if I can debug these ELF files on LLDB with minimal changes which does not require a full (or proper) linking step and would appreciate any pointers on that. Thanks, Ramana ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Failure connecting to lldb-server running in local virtual machine.
Hi, I’ve been hitting issues connecting to lldb-server. I’ve been trying from Mac to Linux running in a Virtual Box VM on the same machine. Once I’ve created a target and issued the “run” command lldb immediately disconnects with “error: connect remote failed (failed to get reply to handshake packet)”. The full output from a failed connection attempting to debug a simple "Hello World!" program is: --- (lldb) platform select remote-linux Platform: remote-linux Connected: no (lldb) platform connect connect://127.0.0.1:1234 Platform: remote-linux Triple: x86_64-pc-linux-gnu OS Version: 4.8.0 (4.8.0-22-generic) Kernel: #24-Ubuntu SMP Sat Oct 8 09:15:00 UTC 2016 Hostname: hhellyer-VirtualBox Connected: yes WorkingDir: /home/hhellyer (lldb) target create hello.out Current executable set to 'hello.out' (x86_64). (lldb) run error: connect remote failed (failed to get reply to handshake packet) error: process launch failed: failed to get reply to handshake packet -- I’m running the server (on Linux) with: >lldb-server platform --listen *:1234 -P 2345 (I need to specify the -P as only a few ports are forwarded from the VirtualBox vm.) With logging enabled the logs showed the failure happened when the lldb-server received the "QStartNoAckMode" packet. I initially thought this was a timing issue on the connection between the client and the server. After doing some investigation I ended up adding code to dump a backtrace when the connection was disconnected (in Communication::Disconnect) and suddenly running the target started working. I replaced the backtrace with a sleep(1) call and it continued working. After that I setup another remote virtual linux box (actually some distance away on the network) and found that lldb worked fine connecting to the remote lldb-server there, presumably because the connection was much slower. At this point I was assuming it was a timing issue however another configuration that worked was lldb-server and lldb both running on the Linux VM inside Virtual Box which I would have assumed would also be very quick. I’m also wondering if lldb does anything special when the connection goes to 127.0.0.1 that using a local VM might confuse. I was testing from Mac to Virtual Box just because it was simpler than testing to a remote system, which was actually the goal and seems to work, so this isn’t totally blocking me but it does seem like a problem and I'm not sure if other users connecting to remote linux machine will hit this problem. Are there any known issues around this type of connection already? Or does anyone have any useful pointers? I couldn’t see anything quite the same on http://bugs.llvm.org/ so asking here seemed like a logical next step. Thanks, Howard Hellyer IBM Runtime Technologies, IBM Systems Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Debugging ELF relocatable files using LLDB
> On Feb 16, 2017, at 3:51 AM, Ramana via lldb-dev
> wrote:
>
> It looks like LLDB doesn't like ELF relocatable files for debugging
> and asserts with the following message when tried
>
> /lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2228:
> unsigned int ObjectFileELF::RelocateSection(.): Assertion `false
> && "unexpected relocation type"' failed.
>
> Are we not supposed to debug ELF relocatable files on LLDB or am I
> missing something?
>
> If we cannot debug the relocatable files, is it _simply_ because those
> files lack program headers (program memory map) and relocations are
> yet to be processed (for debug info) or there are other reasons?
>
> For our target, the assembler output itself is a self contained ELF
> and hence will not have external references (both code and data). I am
> wondering if I can debug these ELF files on LLDB with minimal changes
> which does not require a full (or proper) linking step and would
> appreciate any pointers on that.
>
> Thanks,
> Ramana
Looks like you just need to add support for the 32 bit relocations:
if (hdr->Is32Bit()) {
switch (reloc_type(rel)) {
case R_386_32:
case R_386_PC32:
default:
assert(false && "unexpected relocation type");
}
} else {
switch (reloc_type(rel)) {
case R_X86_64_64: {
symbol = symtab->FindSymbolByID(reloc_symbol(rel));
if (symbol) {
addr_t value = symbol->GetAddressRef().GetFileAddress();
DataBufferSP &data_buffer_sp = debug_data.GetSharedDataBuffer();
uint64_t *dst = reinterpret_cast(
data_buffer_sp->GetBytes() + rel_section->GetFileOffset() +
ELFRelocation::RelocOffset64(rel));
*dst = value + ELFRelocation::RelocAddend64(rel);
}
break;
}
case R_X86_64_32:
case R_X86_64_32S: {
symbol = symtab->FindSymbolByID(reloc_symbol(rel));
if (symbol) {
addr_t value = symbol->GetAddressRef().GetFileAddress();
value += ELFRelocation::RelocAddend32(rel);
assert(
(reloc_type(rel) == R_X86_64_32 && (value <= UINT32_MAX)) ||
(reloc_type(rel) == R_X86_64_32S &&
((int64_t)value <= INT32_MAX && (int64_t)value >= INT32_MIN)));
uint32_t truncated_addr = (value & 0x);
DataBufferSP &data_buffer_sp = debug_data.GetSharedDataBuffer();
uint32_t *dst = reinterpret_cast(
data_buffer_sp->GetBytes() + rel_section->GetFileOffset() +
ELFRelocation::RelocOffset32(rel));
*dst = truncated_addr;
}
break;
}
case R_X86_64_PC32:
default:
assert(false && "unexpected relocation type");
}
}
I am guessing you will do something similar to the x86-64 stuff.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Failure connecting to lldb-server running in local virtual machine.
> On Feb 16, 2017, at 5:58 AM, Howard Hellyer via lldb-dev
> wrote:
>
> Hi,
>
> I’ve been hitting issues connecting to lldb-server. I’ve been trying from Mac
> to Linux running in a Virtual Box VM on the same machine. Once I’ve created a
> target and issued the “run” command lldb immediately disconnects with “error:
> connect remote failed (failed to get reply to handshake packet)”. The full
> output from a failed connection attempting to debug a simple "Hello World!"
> program is:
>
> ---
> (lldb) platform select remote-linux
> Platform: remote-linux
> Connected: no
> (lldb) platform connect connect://127.0.0.1:1234
> Platform: remote-linux
> Triple: x86_64-pc-linux-gnu
> OS Version: 4.8.0 (4.8.0-22-generic)
> Kernel: #24-Ubuntu SMP Sat Oct 8 09:15:00 UTC 2016
> Hostname: hhellyer-VirtualBox
> Connected: yes
> WorkingDir: /home/hhellyer
> (lldb) target create hello.out
> Current executable set to 'hello.out' (x86_64).
> (lldb) run
> error: connect remote failed (failed to get reply to handshake packet)
> error: process launch failed: failed to get reply to handshake packet
> --
>
> I’m running the server (on Linux) with:
> >lldb-server platform --listen *:1234 -P 2345
> (I need to specify the -P as only a few ports are forwarded from the
> VirtualBox vm.)
>
> With logging enabled the logs showed the failure happened when the
> lldb-server received the "QStartNoAckMode" packet.
this is just the first packet we send after sending the "ack" down to the
remote server. When we send the "ack", we don't need a response, then we send
the "QStartNoAckMode" packet and actually wait for a response. If we don't get
one, then we bail. So this is just the first packet that is sent that expects a
response.
> I initially thought this was a timing issue on the connection between the
> client and the server. After doing some investigation I ended up adding code
> to dump a backtrace when the connection was disconnected (in
> Communication::Disconnect) and suddenly running the target started working. I
> replaced the backtrace with a sleep(1) call and it continued working. After
> that I setup another remote virtual linux box (actually some distance away on
> the network) and found that lldb worked fine connecting to the remote
> lldb-server there, presumably because the connection was much slower.
We seem to have a race condition here. Any help figuring out what that might be
would be great.
>
> At this point I was assuming it was a timing issue however another
> configuration that worked was lldb-server and lldb both running on the Linux
> VM inside Virtual Box which I would have assumed would also be very quick.
> I’m also wondering if lldb does anything special when the connection goes to
> 127.0.0.1 that using a local VM might confuse.
So a little background on what happens:
- You launch lldb-server in platform mode on the remote host (VM in your case)
- We attach to it from LLDB on your host machine like you did above
- When we want to debug something on the other side ("run" command above), we
send a packet to the lldb-server on the remote host and ask it to launch a GDB
server for us. The lldb-server does launch one and sends back a hostname
() and a port () in the response. The host side LLDB then tries
to connect to this IP address and port using the equivalent of:
(lldb) process connect connect://:
So the question is: does your VM have a unique IP address? if so, no port
mapping will need to be done. If it responds with 127.0.0.1, then we have port
collision issues and will probably need to use a port offsets. Typically with
VMs there is some port remapping that has to happen. If you and your VM are
both listening for a connection on port 1234, what happens if you would do:
(lldb) platform connect connect://127.0.0.1:1234
Would it connect to your host machine, or the VM? Typically there are some port
remapping settings that you do. Like "add 1" to any ports for the VM, so
you would then just do:
(lldb) platform connect connect://127.0.0.1:11234
Notice the extra 1 added to the original 1234.
When starting the lldb-server in platform mode, you can ask it to use a min and
max port range for connections so that you can edit your VM settings so that
certain ports are available:
% lldb-server platform --listen '*:1000' --min-gdbserver-port 1001
--max-gdbserver-port 1010 --port-offset=1
This would listen on port 1000, and reserver 1001 - 1010 for GDB remote
connections when the server is asked to spawn a lldb-server in debug mode.
Since you specified your port offset of 1, when a packet is sent to your
"lldb-server platform" that asks it to start a lldb-server for debugging it
will use a port between 1001 and 1010 and when it sends the info back to the
client it will add the port offset, so it will send back "11001" as the first
port to connect to and the port remapping will know to talk to your
[lldb-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)
Hello all, GSOC is around the corner, and the LLVM projects plans to participate again this year. For those who don’t know about GSOC, students are proposing a project that they will work on for 3 months. Amongst other, one goal for LLVM is to mentor students to become good developers and also contributors to the LLVM project (or user/advocate of LLVM for building other cool projects). A key part of the process is about how do we select the projects. The way we’ve done it last year, is that the volunteer mentors shared an email thread and ultimately each one individually ranked the projects. We kept the average grading for each project to ranked them overall. In order to make the process more transparent to student applicants, we want to formalize and announce the criteria for ranking and selection project. The purpose of this email is to gather community feedback about the criterion that mentors should apply when ranking projects, for example: - Should we favor a student which has past contributions to LLVM compared to a newcomer? Is it more important or as equally important as the quality of the proposal? - How should we rank (if any) “research or unbounded projects” vs “project with an immediate application”? Should we strive to keep a balance? - What about “projects that touch LLVM/Clang/…” vs “projects that are building something on top of LLVM”? (For example this project was first proposed to be selected by LLVM before being rejected and finally picked by the Julia project directly: https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/ )? - Should we ask that the work is done upstream all along? In the past there have been project developed on GitHub outside the community that have never been merged. The LLVM developer policy has a full section insisting on incremental development ( http://llvm.org/docs/DeveloperPolicy.html#incremental-development ). Hopefully we should be able to provide a set of guidelines to student that would help them fill the best application, and avoid unfortunate surprise at the end of the process. We should have this discussion before receiving the projects proposals, which opens on 2/28. Best, -- Mehdi ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
