[lldb-dev] Using file-defined registers on Android
Todd Fiala
tfiala at google.com
Mon Dec 2 08:58:45 PST 2013
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/6719246b/attachment.html>
More information about the lldb-dev
mailing list