[Lldb-commits] [PATCH] ObjectFileELF::GetSectionHeaderInfo sets arch_spec unnecessarily

[Matthew Gardiner]

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.