<div dir="ltr">I uploaded a CL for review what fixes the crash you are experimenting at <a href="https://reviews.llvm.org/D30251">https://reviews.llvm.org/D30251</a> (we are mapping the files into memory as read only and then trying to write into it) but I think nobody tests LLDB with relocable object files so you might run into a lot of bugs in the way. Also I suggest to switch to a newer version of LLDB (preferably ToT) as 3.6 is fairly old and known to have a lot of bugs on Linux and on ARM.<div><br></div><div>Tamas</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 22, 2017 at 4:56 AM Ramana via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Feb 16, 2017 at 10:26 PM, Greg Clayton <<a href="mailto:gclayton@apple.com" class="gmail_msg" target="_blank">gclayton@apple.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> On Feb 16, 2017, at 3:51 AM, Ramana via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a>><br class="gmail_msg">
> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> It looks like LLDB doesn't like ELF relocatable files for debugging<br class="gmail_msg">
> and asserts with the following message when tried<br class="gmail_msg">
><br class="gmail_msg">
> <path to>/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2228:<br class="gmail_msg">
> unsigned int ObjectFileELF::RelocateSection(.....): Assertion `false<br class="gmail_msg">
> && "unexpected relocation type"' failed.<br class="gmail_msg">
><br class="gmail_msg">
> Are we not supposed to debug ELF relocatable files on LLDB or am I<br class="gmail_msg">
> missing something?<br class="gmail_msg">
><br class="gmail_msg">
> If we cannot debug the relocatable files, is it _simply_ because those<br class="gmail_msg">
> files lack program headers (program memory map) and relocations are<br class="gmail_msg">
> yet to be processed (for debug info) or there are other reasons?<br class="gmail_msg">
><br class="gmail_msg">
> For our target, the assembler output itself is a self contained ELF<br class="gmail_msg">
> and hence will not have external references (both code and data). I am<br class="gmail_msg">
> wondering if I can debug these ELF files on LLDB with minimal changes<br class="gmail_msg">
> which does not require a full (or proper) linking step and would<br class="gmail_msg">
> appreciate any pointers on that.<br class="gmail_msg">
><br class="gmail_msg">
> Thanks,<br class="gmail_msg">
> Ramana<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> Looks like you just need to add support for the 32 bit relocations:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> if (hdr->Is32Bit()) {<br class="gmail_msg">
> switch (reloc_type(rel)) {<br class="gmail_msg">
> case R_386_32:<br class="gmail_msg">
> case R_386_PC32:<br class="gmail_msg">
> default:<br class="gmail_msg">
> assert(false && "unexpected relocation type");<br class="gmail_msg">
> }<br class="gmail_msg">
> } else {<br class="gmail_msg">
> switch (reloc_type(rel)) {<br class="gmail_msg">
> case R_X86_64_64: {<br class="gmail_msg">
> symbol = symtab->FindSymbolByID(reloc_symbol(rel));<br class="gmail_msg">
> if (symbol) {<br class="gmail_msg">
> addr_t value = symbol->GetAddressRef().GetFileAddress();<br class="gmail_msg">
> DataBufferSP &data_buffer_sp = debug_data.GetSharedDataBuffer();<br class="gmail_msg">
> uint64_t *dst = reinterpret_cast<uint64_t *>(<br class="gmail_msg">
> data_buffer_sp->GetBytes() + rel_section->GetFileOffset() +<br class="gmail_msg">
> ELFRelocation::RelocOffset64(rel));<br class="gmail_msg">
> *dst = value + ELFRelocation::RelocAddend64(rel);<br class="gmail_msg">
> }<br class="gmail_msg">
> break;<br class="gmail_msg">
> }<br class="gmail_msg">
> case R_X86_64_32:<br class="gmail_msg">
> case R_X86_64_32S: {<br class="gmail_msg">
> symbol = symtab->FindSymbolByID(reloc_symbol(rel));<br class="gmail_msg">
> if (symbol) {<br class="gmail_msg">
> addr_t value = symbol->GetAddressRef().GetFileAddress();<br class="gmail_msg">
> value += ELFRelocation::RelocAddend32(rel);<br class="gmail_msg">
> assert(<br class="gmail_msg">
> (reloc_type(rel) == R_X86_64_32 && (value <= UINT32_MAX)) ||<br class="gmail_msg">
> (reloc_type(rel) == R_X86_64_32S &&<br class="gmail_msg">
> ((int64_t)value <= INT32_MAX && (int64_t)value >=<br class="gmail_msg">
> INT32_MIN)));<br class="gmail_msg">
> uint32_t truncated_addr = (value & 0xFFFFFFFF);<br class="gmail_msg">
> DataBufferSP &data_buffer_sp = debug_data.GetSharedDataBuffer();<br class="gmail_msg">
> uint32_t *dst = reinterpret_cast<uint32_t *>(<br class="gmail_msg">
> data_buffer_sp->GetBytes() + rel_section->GetFileOffset() +<br class="gmail_msg">
> ELFRelocation::RelocOffset32(rel));<br class="gmail_msg">
> *dst = truncated_addr;<br class="gmail_msg">
> }<br class="gmail_msg">
> break;<br class="gmail_msg">
> }<br class="gmail_msg">
> case R_X86_64_PC32:<br class="gmail_msg">
> default:<br class="gmail_msg">
> assert(false && "unexpected relocation type");<br class="gmail_msg">
> }<br class="gmail_msg">
> }<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> I am guessing you will do something similar to the x86-64 stuff.<br class="gmail_msg">
<br class="gmail_msg">
I tried to mimic the x86_64 relocations handling for our target but<br class="gmail_msg">
getting segmentation fault while trying to write to the 'dst'<br class="gmail_msg">
location.<br class="gmail_msg">
<br class="gmail_msg">
In fact, the x86_64 also segfaults while trying to write to 'dst'<br class="gmail_msg">
location. I just tried to debug the following simple program for<br class="gmail_msg">
x86_64.<br class="gmail_msg">
<br class="gmail_msg">
main.c:<br class="gmail_msg">
int main () {<br class="gmail_msg">
return 0;<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
$ clang main.c -o main_64b.o --target=x86_64 -c -g<br class="gmail_msg">
$ lldb main_64b.o<br class="gmail_msg">
(lldb) target create "main_64b.o"<br class="gmail_msg">
Current executable set to 'main_64b.o' (x86_64).<br class="gmail_msg">
(lldb) source list<br class="gmail_msg">
Segmentation fault (core dumped)<br class="gmail_msg">
<br class="gmail_msg">
Am I doing something wrong or support for debugging the x86_64 ELF<br class="gmail_msg">
relocatable files using LLDB is broken?<br class="gmail_msg">
<br class="gmail_msg">
BTW, I am using LLVM v3.6 and LLDB v3.6.<br class="gmail_msg">
<br class="gmail_msg">
Regards,<br class="gmail_msg">
Ramana<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
lldb-dev mailing list<br class="gmail_msg">
<a href="mailto:lldb-dev@lists.llvm.org" class="gmail_msg" target="_blank">lldb-dev@lists.llvm.org</a><br class="gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class="gmail_msg">
</blockquote></div>