This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] nto target: fix null pointer dereference
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: aristovski at qnx dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 13 Aug 2008 15:29:11 +0200 (CEST)
- Subject: Re: [patch] nto target: fix null pointer dereference
Aleksandar Ristovski wrote:
> Ulrich Weigand wrote:
> > Can you explain what the situation is that leads to a NULL
> > pointer here?
>
> Your question made me go through the issue again.
>
> To create inferior, we use spawnp. spawnp will do something like mmap
> the binary and that's pretty much it (DT_DEBUG in .dynamic will contain
> NULL pointer).
>
> In procfs_create_inferior we call solib_create_inferior_hook, which will
> end up trying to determine loader base by reading inferior's memory at
> DT_DEBUG pointer. In our case, before the executable actually started
> executing, it will successfully read 0s, because dynamic loader has not
> been invoked yet, and the pointer to r_debug structure is not initialized.
I see. However, so->lm_info->lm should still be always allocated by the
common solib-svr4.c routines (see svr4_current_sos):
new->lm_info->l_addr = (CORE_ADDR)-1;
new->lm_info->lm_addr = lm;
new->lm_info->lm = xzalloc (lmo->link_map_size);
The only case where it is not allocated is in svr4_default_sos (which I
guess can happen in your case if the loader base is not found).
However, there the comment says:
/* Nothing will ever check the cached copy of the link
map if we set l_addr. */
new->lm_info->l_addr = debug_loader_offset;
new->lm_info->lm_addr = 0;
new->lm_info->lm = NULL;
Note the assumption that <lm> is only every used if <l_addr> is
not equal to -1. This is also what the solib-svr4.c implementation
of LM_ADDR_CHECK does.
It seems the main problem is that NTO at some time copied some of
the logic from solib-svr4.c, but has not adapted to the changes that
were added to that file later on. Not even the definition of struct
lm_info matches any more!
Maybe a more correct fix would be to mimic the new solib-svr4.c logic
and use the l_addr field to cache the load address?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com