corelow and threads question
Aleksandar Ristovski
aristovski@qnx.com
Fri Jun 5 19:41:00 GMT 2009
Pedro Alves wrote:
> On Friday 05 June 2009 19:54:54, Aleksandar Ristovski wrote:
>
>> With corelow.c patched as proposed, on Neutrino I could do this:
>>
>> For NTO, I "hijack" core_ops:
>> static void
>> init_nto_core_ops ()
>> {
>> struct target_ops *core_ops;
>>
>> core_ops = find_core_target ();
>> gdb_assert (core_ops && core_ops->to_shortname != NULL
>> && !!"core_ops must be initialized first!");
>> original_core_ops = *core_ops;
>> core_ops->to_extra_thread_info =
>> nto_target_extra_thread_info;
>> core_ops->to_open = nto_core_open;
>> core_ops->to_xfer_partial = nto_core_xfer_partial;
>> core_ops->to_pid_to_str = nto_pid_to_str;
>> }
>
> As I mentioned in the other threads, this is fine as a local change,
> but not so to have in GDB proper, so it does go against
> your goal of pushing all your local changes. :-/
>
> This is depending on the order of which the _initialize
> routines are called, hence the gdb_assert. I just cleaned
> up the only left over target that was doing a similar hack
> (sol-threads.c) a couple of months ago, to not do so.
>
> Again, it's hard to come up with a better alternative
> without knowing what you're doing in those overrides. Maybe
> what you need is a thread_stratum target sitting on top of
> nto-procfs.c or corelow.c. Maybe we need new gdbarch
> callbacks.
>
Ok, I attached my nto-diff (work-in-progress) that compile
with current gdb HEAD sources (with some tweaks in configure
scripts). You will see all my hacks there.
I am inclined to think that core_ops is the right way to go;
at which point should I do a "push_target" in that case?
--
Aleksandar Ristovski
QNX Software Systems
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nto.diff
Type: text/x-patch
Size: 46511 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb/attachments/20090605/07d20430/attachment.bin>
More information about the Gdb
mailing list