Thank you for the interest.
Personally, I wouldn't mind just adding gcore to the base package, as it
isn't very large. However, it really is a support script that isn't
necessary for gdb or gdb-server. It does make testing the other part of
the patch easier, though. But as it isn't strictly necessary, I opted
to let people opt in or out of having it.
I am hoping in the future there will be a way to view available packages
so end users can browse a list and add things without having to have
pre-knowledge that it exists to go looking for it.
I do not think the -dbg symbols should be a requirement of the gcore
package. It wasn't while using gcore that I found the missing
dependency, but actually trying to analyze crash dumps created with gdb
installed on the device and a segfaulting multi-threaded program. All
core files produced would have no more than one usable thread's data in
it, and it never seemed to be from the crashing thread. OS level crash
dumps and gdb debugging of the application both were not properly
functional until those symbols were placed on the device, after which
both worked. Therefore, it seems appropriate to place the dependency
against the gdb package as it fixes a defect with the program installed
by that package. While I haven't been using gdb-server on the device,
the research I did pointed to that program also needing those symbols,
so the dependency was added there too.
As I have never used a system that didn't have gdb installed, I am not
sure whether core dumps can be generated without the debugger installed.
If they can, perhaps the eglibc package itself should be made NO_STRIP
or else eglibc made to recommend it's own debug symbols. I don't really
like the no strip idea, as stripped binaries are smaller and thus faster
to load and these symbols are not needed very often, so why force them
to be loaded all the time, but it is an option.
As far as testing this, I could make a small multi-threaded application
that intentionally dereferences a null pointer in one of 4 threads
spawned. That can show the broken nature of gdb core generation without
the thread library symbols. If this is needed, I will put one together
and just reply here that it can be pulled from the poky-contrib
repository. I found and resolved the problem while working on a project
my company is not yet ready to release.
However, if you just want to see that gdb doesn't handle threads
properly, you can just pick a multi-threaded program, do a core dump
(the gcore script makes this trivial), and then load the core file in a
debugger on the development system. Even though the development system
has the symbols, that core won't be readable except for one thread.
I will do another patch fixing the commit message and incorporating
improvements we identify during this discussion.
Brian
On Fri, 2013-11-01 at 09:32 -0700, Khem Raj wrote:
>
>
> On Friday, November 1, 2013, Burton, Ross wrote:
>
> On 31 October 2013 06:54, blloyd <bll...@familyhonor.net>
> wrote:
> > +FILES_gcore = "${bindir}/gcore"
>
> Why can't this script just be added to the gdb package?
>
>
>
> actually if we have it as a separate package then all those new
> rrcommends baggage can be added to gcore package instead of gdb proper
>
>
>
> Ross
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
