This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unwind support for Linux 2.6 vsyscall DSO


Roland McGrath <roland@redhat.com> writes:

> > > Should this SOLIB_ADD then just store whether it has checked yet and clear
> > > that record in SOLIB_CLEAR?
> > 
> > I think that's what it would take.  Open to better ideas, I'm just
> > doing the best I can. :)
> 
> Ok.  I don't see a problem with this if the sequence of when SOLIB_ADD and
> SOLIB_CLEAR will be called is correct.  That is, SOLIB_ADD after core load,
> after attach, or after the break-on-exec (second one) from run, and
> SOLIB_CLEAR some appropriate time for unloading symbols.  It's important
> that SOLIB_ADD not be called too early in the run case, i.e. before the
> second exec so that the inferior's state is not yet as it will be.
> Can I rely on that not happening?

I think you can rely on SOLIB_ADD not being called too early.  It
would be a bug if we ever called it before the shell execs the
executable under debug, because we use the VMA of the .dynamic
section of the executable file to find the dynamic structure in the
inferior's memory anyway.  We couldn't even find the shell's shared
library list.


> > When I say "target vector", I mean 'struct target_ops', not 'struct
> > gdbarch'.  
> 
> I understood you.  My only point was that the notion of such a hook is
> ELF-specific and so perhaps that says something about whether an addition
> of a hook to the generic target_ops structure is appropriate.

I'm wondering how the core / live process distinction gets made when
we need to find the auxilliary vector.  The code reading the vsyscall
library from memory should just read memory from whatever target is
there, and it seems like the aux vector should work the same way.

> Ok.  A function quite that specific seems really pointless to me.  Some
> sort of `bfd_elf_decode_auxv' that either gives an AT_* value to search
> for, or translates one or all entries into Elf_Internal_Auxv format seems
> more appropriate.  e.g.:
> 
> bfd_error bfd_elf_decode_auxv (bfd *, char **data, bfd_size_type *nbytes,
> 			       Elf_Internal_Auxv *element);
> 
> used as in:
> 
> 	{
> 	  Elf_Internal_Auxv av;
> 	  char *p = contents;
> 	  bfd_size_type n = contents_size;
> 	  while (bfd_elf_decode_auxv (abfd, &p, &n, &av) == bfd_error_no_error)
> 	    if (av.a_type == AT_SYSINFO_EHDR)
> 	      {
> 		do_stuff (av.a_val);
> 		break;
> 	      }
> 	}
> 
> or:
> 
> bfd_error bfd_elf_auxv_extract (bfd *, char *data, bfd_size_type nbytes,
> 			        bfd_vma tag, bfd_vma *val);
> 
> used as in:
> 
> 	{
> 	  bfd_vma val;
> 	  if (bfd_elf_auxv_extract (abfd, contents, contents_size,
> 				    AT_SYSINFO_EHDR, &val) == bfd_error_no_error)
> 	    do_stuff (av.a_val);
> 	}

The latter seems nicer to me.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]