From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Pedro Alves <palves@redhat.com>, Tom Tromey <tromey@redhat.com>,
gdb-patches@sourceware.org
Subject: Re: RFC for: "Re: Regression for gdb.fortran/library-module.exp [Re: [RFA] choose symbol from given block's objfile first.]"
Date: Fri, 18 May 2012 17:46:00 -0000 [thread overview]
Message-ID: <20120518164815.GA11883@host2.jankratochvil.net> (raw)
In-Reply-To: <20120516195718.GA10253@adacore.com>
On Wed, 16 May 2012 21:57:18 +0200, Joel Brobecker wrote:
> --- a/gdb/objfiles.c
> +++ b/gdb/objfiles.c
[...]
> +void
> +iterate_over_objfiles_in_search_order
> + (iterate_over_objfiles_in_search_order_cb cb,
> + void *cb_data,
> + struct objfile *context_objfile)
> +{
> + int stop = 0;
> + struct objfile *objfile;
> +
> + if (context_objfile && context_objfile->flags & OBJF_MAINLINE)
> + {
> + stop = cb (context_objfile, cb_data);
> + if (stop)
> + return;
> + }
> +
> + ALL_OBJFILES (objfile)
> + {
> + if (objfile->flags & OBJF_MAINLINE && objfile != context_objfile)
> + {
> + stop = cb (objfile, cb_data);
> + if (stop)
> + return;
> + }
> + }
I see a bit problem this function is objfile based and not solib based, as the
solib order from svr4_current_sos() is completely lost here.
That is if we have two shared libraries with global variable X ld.so defines
which one gets used depending on their dlopen order.
so_list_head already has wrong order due to update_solib_list. Maybe
update_solib_list should be fixed to keep both so_list_head order and also
properly ensure matching objfiles order.
If someone does some add-symbol-file by hand the order gets lost anyway.
Maybe we could ensure just so_list_head order, place this "correct order
search" to elf_lookup_lib_symbol and fall back to the old unfixed objfiles
search in arbitrary order to keep add-symbol-file working.
Sure there should be some exceptions for hidden symbols but this should be
implementable on top of your CONTEXT_OBJFILE being there probably for this
purpose. Plus weak symbols.
> +
> + if (context_objfile && !(context_objfile->flags & OBJF_MAINLINE))
> + {
> + stop = cb (context_objfile, cb_data);
> + if (stop)
> + return;
> + }
> +
> + ALL_OBJFILES (objfile)
> + {
> + if (!(objfile->flags & OBJF_MAINLINE) && objfile != context_objfile)
> + {
> + stop = cb (objfile, cb_data);
> + if (stop)
> + return;
> + }
> + }
> +}
I do not see why to use the OBJF_MAINLINE exceptions here. I see the correct
order is just the most simple ALL_OBJFILES loop.
Maybe you could re-state the case you were trying to fix as your testcase
gdb.base/print-file-var.exp false PASS [Re: [RFA] choose symbol from given block's objfile first.]
http://sourceware.org/ml/gdb-patches/2012-05/msg00692.html
is wrong.
address_info ("info addr") function is wrong but it does not apply for
"print".
Thanks,
Jan
next prev parent reply other threads:[~2012-05-18 17:46 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-07 22:43 [RFC] choose symbol from given block's objfile first Joel Brobecker
2012-05-08 17:19 ` Tom Tromey
2012-05-09 19:05 ` [RFA] " Joel Brobecker
2012-05-09 19:08 ` Joel Brobecker
2012-05-09 20:15 ` Tom Tromey
2012-05-09 20:40 ` Joel Brobecker
2012-05-09 20:57 ` Tom Tromey
2012-05-09 21:06 ` Joel Brobecker
2012-05-10 13:42 ` Tom Tromey
2012-05-10 16:27 ` checked in: " Joel Brobecker
2012-05-10 17:19 ` Joel Brobecker
2012-05-09 21:48 ` Joel Brobecker
2012-05-09 21:49 ` Joel Brobecker
2012-05-18 16:10 ` gdb.base/print-file-var.exp false PASS [Re: [RFA] choose symbol from given block's objfile first.] Jan Kratochvil
2012-05-18 17:17 ` Joel Brobecker
2012-05-18 17:37 ` Jan Kratochvil
2012-05-09 20:08 ` [RFA] choose symbol from given block's objfile first Tom Tromey
2012-05-11 7:26 ` Regression for gdb.fortran/library-module.exp [Re: [RFA] choose symbol from given block's objfile first.] Jan Kratochvil
2012-05-11 12:25 ` Joel Brobecker
2012-05-14 14:39 ` Joel Brobecker
2012-05-14 14:52 ` Jan Kratochvil
2012-05-14 15:06 ` Joel Brobecker
2012-05-14 15:15 ` Jan Kratochvil
2012-05-14 16:57 ` Joel Brobecker
2012-05-14 17:05 ` Jan Kratochvil
2012-05-14 17:49 ` Pedro Alves
2012-05-14 17:59 ` Joel Brobecker
2012-05-14 18:07 ` Jan Kratochvil
2012-05-15 13:09 ` Joel Brobecker
2012-05-16 19:57 ` RFC for: "Re: Regression for gdb.fortran/library-module.exp [Re: [RFA] choose symbol from given block's objfile first.]" Joel Brobecker
2012-05-18 17:46 ` Jan Kratochvil [this message]
2012-05-28 14:27 ` Joel Brobecker
2012-05-28 16:12 ` Jan Kratochvil
2012-05-29 15:44 ` Joel Brobecker
2012-05-29 15:49 ` Joel Brobecker
2012-05-29 15:56 ` Jan Kratochvil
2012-05-29 16:02 ` Joel Brobecker
2012-05-29 16:12 ` Jan Kratochvil
2012-05-29 16:31 ` Pedro Alves
2012-05-10 14:14 ` [RFC] choose symbol from given block's objfile first Pedro Alves
2012-05-10 14:32 ` Tom Tromey
2012-05-10 14:50 ` Matt Rice
2012-05-10 15:07 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120518164815.GA11883@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox