Todd Fiala wrote:
> Please note that I copied a lot of the PlatformLinux code into
PlatformKalimba
Oh shucks, I have a boatload of changes going into PlatformLinux to
support remote debugging! I've been stuck the last week dealing with
testing, Windows-related builds/issues, and other minutiae but I am
looking to getting back to this. You can keep your eyes on the
changes I check in for PlatofrmLinux to support llgs. I'll be
refactoring a bunch of code in PlatformDarwin into PlatformPOSIX, and
changing a few more details in PlatformLinux.
Thanks, that could be useful. One of the things I need to do with
PlatformKalimba is enable the "platform process" command pull back data
about remote targets. This type of data would assist me in supplying
non-intrusive debug of the kalimbas . Greg floated an idea where I think
could use platform process/list/info to get data which may include the
run state of connected (by SPI wire) kalimbas. Firstly "list" connected
devices, "PID" being virtual since kailmba (currently) runs no OS:
(lldb) platform process list
PID PARENT USER ARCH NAME
====== ====== ========== ===================== ============================
1 kalimba-csr-unknown kal4 (1 core)
2 kalimba-csr-unknown kal4 (1 core)
Then we could determine whether the chip is running first, before doing
any such *intrusive classic gdb-remote* style (which always forces the
target to stop). Appreciate I may need additional GDB-RSP message to
achieve this...
(lldb) platform process info 1
Process information for process 1:
pid=1
status=running
...
Do you think your PlatformLinux stuff may have some code I can copy
which may help with this area?
> When I invoke "target create kalimba.elf" I actually see
ObjectFileELF::GetSectionHeaderInfo called *several times* whilst the
target is created:
Yeah I have a note to go back to figure out why that's the case. When
I added the note support, I saw it getting called several times when
it seems like it should have been once. The ObjectFileELF was getting
created and destroyed multiple times, which I think was unintended.
I'll look closer into why that's happening.
I've just had a quick look. It looks to me like...
1. PlatformLinux::ResolveExecutable determines if exe is loadable on the
SharedModuleList
error = ModuleList::GetSharedModule (module_spec, exe_module_sp,
but even if error==success, it inspects the exe_module_sp (output by above)
if (!exe_module_sp || exe_module_sp->GetObjectFile() == NULL)
to see, if the GetObjectFile is valid. (If it's NULL ResExec then *fails*).
2. But Module::GetObjectFile() then calls ObjectFileELF::GetArchitecture,
passing it's ArchSpec as a non-const ref.
3. ObjectFileELF::GetArchitecture then calls ParseSectionHeaders
which mutes the spec.
So, with my limited architectural knowledge of lldb, I think another
possible fix would be to change ObjectFileELF::GetArchitecture so that
it does not call ParseSectionHeaders if m_section_headers is non-empty.
This, at least, prevent the static function (GSHI) being called again.
Thanks for reminding me.
> It would be great if we could prevent the arch_spec being modified
again, after the headers are parsed. Either with my patch or something
similar. Anyway, I'm off now, so I'll catch up sometime tomorrow.
Okay, hopefully by then it will all be better :-)
Ok, thanks.
Matt
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
www.youtube.com/user/CSRplc, Facebook,
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at
www.aptx.com.
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
