* Re: getunwind syscall
@ 2003-10-31 19:28 J. Johnston
2003-10-31 20:01 ` Daniel Jacobowitz
2003-10-31 21:42 ` Marcel Moolenaar
0 siblings, 2 replies; 6+ messages in thread
From: J. Johnston @ 2003-10-31 19:28 UTC (permalink / raw)
To: gdb-patches, Andrew Cagney; +Cc: kevinb, davidm
More info from David.
-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getunwind syscall
2003-10-31 19:28 getunwind syscall J. Johnston
@ 2003-10-31 20:01 ` Daniel Jacobowitz
2003-10-31 21:02 ` J. Johnston
2003-10-31 22:49 ` David Mosberger
2003-10-31 21:42 ` Marcel Moolenaar
1 sibling, 2 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2003-10-31 20:01 UTC (permalink / raw)
To: J. Johnston; +Cc: gdb-patches, Andrew Cagney, kevinb, davidm
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.
>
> -- 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
>
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getunwind syscall
2003-10-31 20:01 ` Daniel Jacobowitz
@ 2003-10-31 21:02 ` J. Johnston
2003-10-31 22:49 ` David Mosberger
1 sibling, 0 replies; 6+ messages in thread
From: J. Johnston @ 2003-10-31 21:02 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches, Andrew Cagney, kevinb, davidm
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
>>
>>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getunwind syscall
2003-10-31 19:28 getunwind syscall J. Johnston
2003-10-31 20:01 ` Daniel Jacobowitz
@ 2003-10-31 21:42 ` Marcel Moolenaar
2003-10-31 23:01 ` David Mosberger
1 sibling, 1 reply; 6+ messages in thread
From: Marcel Moolenaar @ 2003-10-31 21:42 UTC (permalink / raw)
To: J. Johnston; +Cc: gdb-patches, Andrew Cagney, kevinb, davidm
On Fri, Oct 31, 2003 at 02:28:10PM -0500, J. Johnston wrote:
> -------- 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.
Just to be unambiguous: I assume it's only the unwind information for
kernel functions that are visible and/or accessable in user space and
not the unwind information for the kernel at large, and the coredump
is one corresponding to a process, not the kernel; right?
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getunwind syscall
2003-10-31 20:01 ` Daniel Jacobowitz
2003-10-31 21:02 ` J. Johnston
@ 2003-10-31 22:49 ` David Mosberger
1 sibling, 0 replies; 6+ messages in thread
From: David Mosberger @ 2003-10-31 22:49 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: J. Johnston, gdb-patches, Andrew Cagney, kevinb, davidm
>>>>> On Fri, 31 Oct 2003 15:01:26 -0500, Daniel Jacobowitz <drow@mvista.com> said:
Daniel> On Fri, Oct 31, 2003 at 02:28:10PM -0500, J. Johnston wrote:
>> More info from David.
Daniel> So the getunwind syscall returns data from the gate DSO?
Almost. It returns the equivalent data as contained in the unwind
tables of the gate DSO. The data itself isn't quite identical, but it
serves the same purpose, yese.
Daniel> I was under the impression it was some register backing
Daniel> store, or similar.
Nope.
Daniel> In that case Roland's patches for the same issue on x86
Daniel> should be persued instead of using the syscall.
Longer-term, certainly. But in the medium term (I'd say for the next
1-2 years at least), we need the syscall support for the many (older)
kernels that are out there already. Only 2.6-based kernels will have
the DSO.
--david
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: getunwind syscall
2003-10-31 21:42 ` Marcel Moolenaar
@ 2003-10-31 23:01 ` David Mosberger
0 siblings, 0 replies; 6+ messages in thread
From: David Mosberger @ 2003-10-31 23:01 UTC (permalink / raw)
To: Marcel Moolenaar; +Cc: J. Johnston, gdb-patches, Andrew Cagney, kevinb, davidm
>>>>> On Fri, 31 Oct 2003 13:42:15 -0800, Marcel Moolenaar <marcel@xcllnt.net> said:
Marcel> On Fri, Oct 31, 2003 at 02:28:10PM -0500, J. Johnston wrote:
>> -------- 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.
Marcel> Just to be unambiguous: I assume it's only the unwind
Marcel> information for kernel functions that are visible and/or
Marcel> accessable in user space and not the unwind information for
Marcel> the kernel at large, and the coredump is one corresponding
Marcel> to a process, not the kernel; right?
Correct.
--david
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-10-31 23:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-31 19:28 getunwind syscall J. Johnston
2003-10-31 20:01 ` Daniel Jacobowitz
2003-10-31 21:02 ` J. Johnston
2003-10-31 22:49 ` David Mosberger
2003-10-31 21:42 ` Marcel Moolenaar
2003-10-31 23:01 ` David Mosberger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox