This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Fix problem with (maybe) non-relocated .opd section on powerpc64-linux
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 16 May 2008 22:35:14 +0200 (CEST)
- Subject: Re: [rfc] Fix problem with (maybe) non-relocated .opd section on powerpc64-linux
Daniel Jacobowitz wrote:
> On Thu, May 15, 2008 at 07:36:33PM +0200, Ulrich Weigand wrote:
> > Kernel modules generally have an opd section; as in other object files,
> > these will carry a R_PPC64_ADDR64 relocation pointing to .text + some
> > offset. (In shared libraries we see a R_PPC_RELATIVE instead.)
> >
> > That means my heuristics will probably go wrong when applied to an
> > object file (or kernel module). When would that actually happen?
>
> Generally, they are loaded with either add-symbol-file (by hand or
> autogenerated) specifying each section. The KGDB guys also have a GDB
> patch to do it automatically. That's one of my targetted applications
> of Python scripting.
Thinking about this, it seems this would mean that function descriptors
cannot work in kernel modules even today: add-symbol-file solely adds
an objfile (with obj_sections and so on); it does not modify the target
and its section table. Right?
However, ppc64_linux_convert_from_func_ptr_addr *by design* only consults
the section table of the target -- this means it will never see those
extra symbol files anyway.
Am I missing something here?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com