[Lldb-commits] [PATCH] ObjectFileELF::GetSectionHeaderInfo sets arch_spec unnecessarily
mg11 at csr.com
Thu Jul 10 23:13:56 PDT 2014
Todd Fiala wrote:
> > Please note that I copied a lot of the PlatformLinux code into
> 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
(lldb) platform process info 1
Process information for process 1:
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
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 :-)
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.
More information about the lldb-commits