Re: getunwind syscall

["J. Johnston" <jjohnstn@redhat.com>]

Daniel Jacobowitz wrote:
> On Fri, Oct 31, 2003 at 02:28:10PM -0500, J. Johnston wrote:
> 
>>More info from David.
> 
> 
> So the getunwind syscall returns data from the gate DSO?  I was under
> the impression it was some register backing store, or similar.  In that
> case Roland's patches for the same issue on x86 should be persued
> instead of using the syscall.
> 
> 

I don't believe that level of complexity is required.  The syscall is only used 
if we fail the find_pc_section() call.  Admittedly, Andrew has comments 
regarding replacing the find_pc_section() and accompanying bfd calls but that is 
an orthogonal issue.  The x86 problem is different in my mind in that gdb 
doesn't have other recourse.  Per comments, I have already changed the syscall 
in ia64-tdep.c to be a call to to_read_partial() which for linux ends up being 
mapped to the syscall within the ia64-linux-nat.c code (I haven't reposted a 
change yet as I want to also get the bfd stuff cleared up too).  Failing all of 
this, the regular prologue examination methods still come into play and they are 
good enough to match libunwind for the gdb testsuite.

-- Jeff J.

>>
>>-------- Original Message --------
>>
>>
>>>>>>>On Thu, 30 Oct 2003 14:20:13 -0500, "J. Johnston" 
>>>>>>><jjohnstn@redhat.com> said:
>>
>>  >> Nothing which involves a syscall is acceptable in a tdep file.
>>  >> That's what the t means - target support.
>>
>>  Andrew> Is this information available via /proc?  In a core file?
>>
>>The unwind info for the Linux kernel does get included in the
>>core-dump (see Roland McGrath's work on this), but it is not available
>>via /proc.  Note that in the future, it won't be necessary to do a
>>syscall.  Instead, the kernel's unwind info will be available (to the
>>running process) via dl_iterate_phdr().  I'm not sure though how this
>>is supposed to be made accessible to programs such as gdb.
>>
>>	--david
>>
>>
> 
>