All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@baldric.uwo.ca>
To: "Boehm, Hans" <hans_boehm@hp.com>
Cc: "'parisc-linux@lists.parisc-linux.org'"
	<parisc-linux@lists.parisc-linux.org>
Subject: Re: [parisc-linux] Program counter from sigcontext, constructurs and -fPIC
Date: Fri, 25 Apr 2003 14:54:14 -0400	[thread overview]
Message-ID: <20030425185414.GD32717@systemhalted> (raw)
In-Reply-To: <75A9FEBA25015040A761C1F74975667D0144204D@hplex4.hpl.hp.com>

Hans,

What code are you porting? :)

> 1) I need to retrieve the pc value from the sigcontext structure passed to a timer signal handler.  In an earlier message, Paul Bame pointed me at sc_iaoq.  After a bit more reading, my conclusion was that sc_iaoq[0] should be a reasonable value to use as a sampled pc.  However I have been unable to see anything reasonable in that slot (or sc_iaoq[1] for that matter).  Presumably a struct sigcontext pointer is always passed as the third parameter to a signal handler?  And it's filled in for timer interrrupts?  What does profil() do?  (I tried to read the code, but it's hard to trace through all the configuration stuff.)

A. What kernel are you using?
 
The reason I ask is that 64-bit kernels return broken sigcontext
pointers (for now it stuffs 64-bit values into a 32-bit values within
the sigcontext, rather it should take into account the fact that
userspace or the calling threads personality is 32-bit and truncate the
register values).

What is there to understand about profil()? Based on your PC it uses
modular arithmetic (the shift, scale, and division) to track on a coarse
scale which parts of your code are being executed.

> 2) If I mark a C function as a constructor function, and compile it with -fPIC, it seems to run before globals are properly accessible.  The retrieval of the address of a global through the global offset table seems to return a bad address and the access faults.  Are there known issues in this area?  (The offending function actually ends up in the main program, if that matters.)

B. Can we see the code?

c.

  reply	other threads:[~2003-04-25 18:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-25 17:46 [parisc-linux] Program counter from sigcontext, constructurs and -fPIC Boehm, Hans
2003-04-25 18:54 ` Carlos O'Donell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-04-25 19:40 Boehm, Hans
2003-04-25 20:52 ` Carlos O'Donell
2003-04-29 21:17 Boehm, Hans
2003-04-29 21:30 ` Carlos O'Donell
2003-04-29 22:13   ` Grant Grundler
2003-04-30  0:31     ` Carlos O'Donell
2003-04-30  5:18       ` Grant Grundler
2003-04-30  7:15       ` Joel Soete
2003-04-30 18:12         ` Carlos O'Donell
2003-05-03 20:48           ` Joel Soete
2003-05-05  6:08             ` Joel Soete
2003-05-01  4:09 ` Grant Grundler
2003-04-30  0:52 Boehm, Hans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030425185414.GD32717@systemhalted \
    --to=carlos@baldric.uwo.ca \
    --cc=hans_boehm@hp.com \
    --cc=parisc-linux@lists.parisc-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.