I'll go ahead and take care of it - no time like the present :-)
On Tue, Dec 3, 2013 at 1:45 AM, Abid, Hafiz <Hafiz_Abid at mentor.com> wrote:
> >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.
>
>
>
> I noticed this too that make install does not put the python related stuff
> to the install location in Linux. I was planning to create a patch for it
> but got distracted. I will probably come back to it sooner if you have not
> already fixed it by then.
>
>
>
> Regards,
>
> Abid
>
>
>
>
>
> *From:* lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu]
> *On Behalf Of *Todd Fiala
> *Sent:* 02 December 2013 22:25
> *To:* Greg Clayton
>
> *Cc:* lldb-dev at cs.uiuc.edu
> *Subject:* Re: [lldb-dev] Using file-defined registers on Android
>
>
>
> > 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/20131203/7c859c87/attachment.html>