> I'm not sure how you were doing the entire setup above
This wasn't using llgs at all, just the local core file support
```
bin/lldb /bin/sleep -c sleep.core
```
Last night I discovered that the triple is `x86_64-unknown-freebsd` with the
patch, and `x86_64-unknown-freebsd10.0` without. The latter matches the
platform triple reported by `platform status`.
With the patch, in `ModuleList::GetSharedModule` the
`module_sp->GetObjectFile()` fails.
================
Comment at: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:1075
@@ -983,1 +1074,3 @@
+ // Process FreeBSD ELF notes.
+ if (note.n_namesz == LLDB_NT_OWNER_FREEBSD_LENGTH && note.n_name ==
LLDB_NT_OWNER_FREEBSD)
{
----------------
Todd Fiala wrote:
> Ed Maste wrote:
> > n_name is a std::string and the length (namesz) should be handled in the
> > note parser so you should be able to just do note.n_name ==
> > LLDB_NT_OWNER_FREEBSD, no?
> >
> > Also for the purpose of this parsing we'll generally have just one case in
> > each of the switch statements - maybe it'd be more concise to just check
> > note.n_type == LLDB_NT_FREEBSD_ABI_TAG in the if() as well?
> > Also for the purpose of this parsing we'll generally have just one case in
> > each of the switch statements - maybe it'd be more concise to just check
> > note.n_type == LLDB_NT_FREEBSD_ABI_TAG in the if() as well?
>
> Sure, I think it's only GNU that is using multiple ones. I can change that
> for the others.
>
> > n_name is a std::string and the length (namesz) should be handled in the
> > note parser so you should be able to just do note.n_name ==
> > LLDB_NT_OWNER_FREEBSD, no?
>
> Yes, but I was looking to avoid the string compare if the length wasn't
> equal. That would stop needing to get the string length of the constant.
> Overall this is likely very minor compared to the cost of scanning the entire
> contents though, so probably worth the simplification.
> Yes, but I was looking to avoid the string compare if the length wasn't
> equal. That would stop needing to get the string length of the constant.
> Overall this is likely very minor compared to the cost of scanning the entire
> contents though, so probably worth the simplification.
Oh, good point. I was probably reading something else into it from my previous
investigations into ELF notes and having to deal with a special case for the
Linux core note n_namesz.
http://reviews.llvm.org/D4302
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
