[lldb-dev] Using file-defined registers on Android
Todd Fiala
tfiala at google.com
Mon Dec 2 14:25:26 PST 2013
> You might want to verify that you can do some rudimentary python first:
> % lldb
> (lldb) script 2+3
Sure enough that found issue #1 :-)
For some reason my install process (autotools-based, standard configure,
make, make install) is not getting the lldb.py and site-packages copied
over to the install tree. I copied these over manually for now to the
`lldb -P` location and at least the sample python script now runs. I've
put a TODO on my list to check back on the makefiles and see what's going
on with the state of the python package installation.
On Mon, Dec 2, 2013 at 8:59 AM, Todd Fiala <tfiala at google.com> wrote:
> > If I do indeed hit strangeness with gdbserver, I may switch gears over
> to working on lldb-server sooner than later (per other threads on that
> topic).
>
> Make that lldb-gdbserver, rather.
>
>
> On Mon, Dec 2, 2013 at 8:58 AM, Todd Fiala <tfiala at google.com> wrote:
>
>> Thanks for all the replies, Greg!
>>
>> I'm going to work through this today.
>>
>> > LLDB will send a "k" packet which tells the remote GDB server to kill
>> the process. The GDB server needs to make sure the process and all its
>> threads are killed. Sounds like a GDB server issue.
>>
>> If I do indeed hit strangeness with gdbserver, I may switch gears over to
>> working on lldb-server sooner than later (per other threads on that topic).
>>
>>
>> On Mon, Dec 2, 2013 at 8:43 AM, Greg Clayton <gclayton at apple.com> wrote:
>>
>>>
>>> On Nov 26, 2013, at 3:57 PM, Todd Fiala <tfiala at google.com> wrote:
>>>
>>> > Hi all,
>>> >
>>> > I'm attempting to follow the platform definition approach that Greg
>>> laid out when attempting to attach to a gdbserver running on an Android
>>> device. In particular, Android arm v7a devices (Nexus 10 and Nexus 7).
>>> >
>>> > I went ahead and created a python register definition. I generated
>>> the definition file based on referencing these:
>>> >
>>> > svn cat
>>> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py
>>> > svn cat
>>> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_target_definition.py
>>> >
>>> > and the output from using one of gdb's commands when gdb was attached
>>> to the gdbserver:
>>> >
>>> > (gdb) maint print raw-registers
>>> >
>>> >
>>> > Now I'm attempting to do some debugging with lldb.
>>> >
>>> > I created an app, fired it up on the Android, and attempt to attach to
>>> the running process. Since I can debug this app fine remotely with gdb, I
>>> believe the basic pipe should be okay.
>>> >
>>> > Here's what I do on the lldb side. The Android app to be debugged is
>>> running at this point.
>>> >
>>> > lldb
>>> >
>>> > # set the platform file
>>> > (lldb) settings set plugin.process.gdb-remote.target-definition-file
>>> /home/tfiala/work/arm-arch/armv7a_linux_target_definition.py
>>> >
>>> > # note I tried to use armv7-pc-linux, which said the file didn't
>>> match, and there
>>> > # doesn't appear to be an armv7a-pc-linux. Should I be using
>>> something else here?
>>> > (lldb) target create --arch arm-pc-linux
>>> libs/armeabi-v7a/libnative-activity.so
>>> >
>>> > # As above, only arm-pc-linux seemed to accept this file. The .so file
>>> > # is an armv7a-built lib in this case and runs fine on Nexus 7 and 10
>>> devices.
>>> > (lldb) file --arch arm-pc-linux libs/armeabi-v7a/libnative-activity.so
>>> >
>>> > # Now ready for the connect: the adb redirector to communicate with
>>> > # gdbserver is localhost:5039
>>> > (lldb) gdb-remote 5039
>>> >
>>> >
>>> > Here's what I get:
>>> > (lldb) thread list
>>> > Process 8176 stopped
>>> > * thread #1: tid = 8176, , stop reason = signal SIGTRAP
>>> > (lldb) bt
>>> > * thread #1: tid = 8176, , stop reason = signal SIGTRAP
>>> > * frame #0:
>>>
>>> It looks like we didn't parse your register definition file correctly.
>>> Try a:
>>>
>>> (lldb) read registers
>>>
>>> I am guessing you will see no output. As already suggested, step through
>>> ProcessGDBRemote::ParsePythonTargetDefinition() and make sure this succeeds.
>>>
>>>
>>> > The app itself is still running on the Android device - at least the
>>> main thread is. So the listing of it as stopped appears to be incorrect.
>>>
>>> Anytime we attach to a GDB server and tell it to attach to a process,
>>> the reply to the "vAttach" packet is a stop reply packet which tells us the
>>> reason the process is stopped ("TXX" where XX is a signal (SIGTRAP in this
>>> case)), and also it tells us about the thread that is stopped and some
>>> expedited register values. After the attach packet, we are assuming your
>>> program must be stopped. The documentation seems to back this up:
>>>
>>> https://sourceware.org/gdb/onlinedocs/gdb/Stop-Reply-Packets.html
>>>
>>> So it sounds like the GDB server might not be doing the right thing
>>> here? We will need to look at the packet log to see what is going on.
>>>
>>> > If I do "(lldb) exit", it will kill the main thread fwiw, but not nuke
>>> the process. I'm not particularly concerned with that piece yet as it
>>> might be related to the dual-heritage java/native aspect.
>>>
>>> LLDB will send a "k" packet which tells the remote GDB server to kill
>>> the process. The GDB server needs to make sure the process and all its
>>> threads are killed. Sounds like a GDB server issue.
>>> >
>>> > I've got the architecture definition file indicating the triple it
>>> provides is arm-*-linux (at least, I think). I have no idea if the file is
>>> working since I haven't (yet) figured out how to get output from the
>>> loading process.
>>>
>>> That might be the problem, try to match the architecture exactly to what
>>> it is for now. I don't believe I made the wildcard matching work yet.
>>>
>>> >
>>> > I'm attaching my architecture definition file and the maintenance dump
>>> in case anybody sees something obviously wrong.
>>> >
>>> > Some questions:
>>> >
>>> > * Am I running the right commands in the right order to connect to a
>>> gdbserver where I'm specifying the register information explicitly? Are
>>> the target and file commands needed with the architecture file?
>>>
>>> You only need to run "target create" _or_ the "file" command. "file" is
>>> an alias to "target create", so you have to execute one of these commands.
>>> You should be able to specify "armv7-pc-linux". I am guessing the
>>> "remote-linux" platform is not liking this? It would be worth stepping
>>> through the code to see why "armv7-pc-linux" us being rejected and by whom.
>>>
>>> >
>>> > * Why is LLDB telling me the armv7a object files are not valid armv7
>>> files?
>>>
>>> We don't currently have "armv7a" in our architecture list. Does
>>> LLVM/clang understand "armv7a"? I would try using "armv7-pc-linux". If
>>> "armv7a" is recognized by LLVM/Clang, feel free to add it by modifying the
>>> code in ArchSpec.cpp. There are a few tables you will need to edit:
>>>
>>> g_core_definitions on ArchSpec.cpp:50
>>>
>>> g_elf_arch_entries on ArchSpec.cpp:228
>>>
>>> The main problem we currently have with ELF, is ELF file tell us "ARM"
>>> and that is it. Is there a note or anything else inside the ELF file that
>>> can help us figure out the exact ARM variant contained in an ELF
>>> executable? If so we need to modify ObjectFileELF:
>>>
>>> bool
>>> ObjectFileELF::GetArchitecture (ArchSpec &arch)
>>> {
>>> if (!ParseHeader())
>>> return false;
>>>
>>> arch.SetArchitecture (eArchTypeELF, m_header.e_machine,
>>> LLDB_INVALID_CPUTYPE);
>>> arch.GetTriple().setOSName (Host::GetOSString().GetCString());
>>> arch.GetTriple().setVendorName(Host::GetVendorString().GetCString());
>>> return true;
>>> }
>>>
>>> Because just "ARM" really isn't enough. The only thing we have to go on
>>> with ELF is the e_machine from the ELF header. If there isn't a way to
>>> detect the correct arch variant for ELF is, we will need to add an LLDB
>>> setting that can be used to set substitute the correct value in when
>>> parsing ARM files and we would use it to change all "ARM" generic
>>> architectures to the result of the setting and this would need to be done
>>> in ObjectFileELF::GetArchitecture(...). It would be better if there is some
>>> data in the ARM ELF files in the object file itself that we can parse
>>> though, so we should pursue this angle first.
>>>
>>> >
>>> > * Is the "pc" part of the arm-pc-linux part right, wrong, or a don't
>>> care for my scenario?
>>>
>>> Not sure. The triple should match what LLVM/Clang thinks the standard
>>> triple should be for ARM on linux.
>>>
>>> >
>>> > * Is it the mere fact that I'm attaching remotely good enough for lldb
>>> to be using the architecture definition specified with "settings set
>>> plugin.process.gdb-remote.target-definition-file ...", or is it keying off
>>> of some of the meta data it has (like me specifying the "target create" and
>>> "file --arch" commands)?
>>>
>>> It might currently be checking the target arch and trying to match it up
>>> to the arch you have in your target definition file. I would remove the
>>> wildcard and have it match exactly what you type for now.
>>>
>>> >
>>> > * How do I debug python loaded via lldb or get feedback from the lldb
>>> python support (e.g. if there's a syntax error or something else goofy)
>>> when running lldb?
>>>
>>> You really can't debug the python right now as far as I know. print
>>> statements are my current choice when things go wrong.
>>>
>>> For the target definition file, set a breakpoint in ProcessGDBRemote.cpp
>>> in ProcessGDBRemote::ParsePythonTargetDefinition(), which currently is line
>>> 334:
>>>
>>> bool
>>> ProcessGDBRemote::ParsePythonTargetDefinition(const FileSpec
>>> &target_definition_fspec)
>>> {
>>> #ifndef LLDB_DISABLE_PYTHON
>>> ScriptInterpreter *interpreter =
>>> GetTarget().GetDebugger().GetCommandInterpreter().GetScriptInterpreter();
>>> Error error;
>>> lldb::ScriptInterpreterObjectSP module_object_sp
>>> (interpreter->LoadPluginModule(target_definition_fspec, error));
>>> if (module_object_sp)
>>> {
>>> lldb::ScriptInterpreterObjectSP target_definition_sp
>>> (interpreter->GetDynamicSettings(module_object_sp,
>>>
>>> &GetTarget(),
>>>
>>> "gdb-server-target-definition",
>>>
>>> error));
>>>
>>> PythonDictionary target_dict(target_definition_sp);
>>>
>>> if (target_dict)
>>> {
>>>
>>> You will want to see that "module_object_sp" is valid and also that
>>> "target_definition_sp" and eventually "target_dict" test true. Let me know
>>> if they don't.
>>>
>>> You might want to verify that you can do some rudimentary python first:
>>>
>>> % lldb
>>> (lldb) script 2+3
>>>
>>>
>>> >
>>> > I assume I have something really basic wrong at this point since the
>>> arch definition file specified seems to make no difference on the output
>>> vs. what I see when I attach with lldb without specifying the architecture
>>> file.
>>>
>>> I am guessing that the arch file is not getting loaded due to the
>>> architecture having a wildcard? Let me know what you find on that end.
>>>
>>> >
>>> > Thanks for any suggestions and for helping fill in my understanding!
>>> >
>>> > Sincerely,
>>> > Todd Fiala
>>> >
>>> <armv7a_linux_target_definition.py><gdb-reg-output-armv7a.out>_______________________________________________
>>> > lldb-dev mailing list
>>> > lldb-dev at cs.uiuc.edu
>>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131202/8e3c6a45/attachment.html>
More information about the lldb-dev
mailing list