> On Feb 13, 2015, at 10:55 AM, Ed Maste <ema...@freebsd.org> wrote:
>
> FreeBSD userland core files have no section table, so the vendor and
> OS detection in ObjectFileELF does not get a chance to set the arch
> spec.
>
> There is a special case in ObjectFileELF::GetSectionHeaderInfo for the
> case that the ELF file and host have the same core (i.e., CPU) type.
> If they do then an unknown OS or vendor is updated to match the host.
>
> Unfortunately this does not work with cross-arch core file debugging -
> e.g. debugging a FreeBSD/aarch64 core file on FreeBSD/i386. I'm using
> the following workaround for now:
>
> ====
> diff --git a/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
> b/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
> index e7bf20e..772adb6 100644
> --- a/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
> +++ b/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
> @@ -1395,8 +1395,11 @@
> ObjectFileELF::GetSectionHeaderInfo(SectionHeaderColl
> §ion_headers,
> }
>
> // If there are no section headers we are done.
> - if (header.e_shnum == 0)
> + if (header.e_shnum == 0) {
> + if (arch_spec.GetTriple().getOS() == llvm::Triple::OSType::UnknownOS)
> + arch_spec.GetTriple().setOSName(HostInfo::GetOSString().data());
> return 0;
> + }
>
> Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_MODULES));
> ====
>
> which isn't quite right, since cross-OS debugging will still not work
> - e.g. opening a FreeBSD/i386 core file on Linux/i386, or a
> FreeBSD/aarch64 core file on Linux/i386.
>
> What I think we need is:
> * Have the special case in ObjectFileELF::GetSectionHeaderInfo not
> take effect for core files, so the arch spec remains e.g.
> aarch64-unknown-unknown
> * Update ObjectFile::SetModulesArchitecture to take a flag specifying
> exact or compatible match, and promote unknown vendor or OS to a
> specified vendor or OS (but not the other way around)
> * Have ObjectFileELF::CreateInstance request a compatible match for
> ELF core files (ET_CORE).
>
> Does that sound reasonable?
It does if there is no other viable work around.
One thing we do on MacOSX is to search through our mach-o core files for data
at the start of memory page boundaries. This helps us to locate the
/usr/lib/dylb mach header and allows us to determine info about the debug
session contained within the core file.
Are there any data structures in the core file memory or ELF headers in memory
you can look at to help you properly determine the contents of a core file and
identify it as FreeBSD or Linux? Try and scrub through the core file contents,
only for ELF core files of course, and try to figure things out.
If not, your approach sounds ok, but scrubbing memory and looking for strings,
certain sections, data structures, magic byte patterns, maybe getting the AUXV
data and figuring out the list of shared libraries that were loaded and then
maybe looking at the path values and figuring out that some of the paths are
FreeBSD or linux specific would go a long way to making a proper determination
of the core files architecture.
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
