This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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: new syscall stub support for ia64 libc


>>>>> On Fri, 31 Oct 2003 15:47:24 +0100, Jakub Jelinek <jakub@redhat.com> said:

  Jakub> On Fri, Oct 31, 2003 at 08:45:22AM -0800, David Mosberger wrote:
  >> >>>>> On Fri, 31 Oct 2003 08:01:14 +0100, Jakub Jelinek <jakub@redhat.com> said:

  Jakub> Cannot tcbhead_t's private field be reused for the sysinfo pointer
  Jakub> actually on IA-64?

  >> As long as we can make it appear at offsets -8, that would be OK.

  Jakub> It would be offset 8, not -8 actually.

Ah, you mean _that_ one.  It's defined by the psABI and since the new
syscall stub was defined much later, I considered it off limits.  I'd
hate to change the offset now, many months after an open discussion on
this topic.  On the other hand, if we do want to change it, now is
probably the last chance.

  Jakub> That way 32 bytes wouldn't have to be wasted at end of struct
  Jakub> pthread, it would be at the same location in linuxthreads as
  Jakub> well as NPTL build

I don't think you have to waste 32 bytes.  You could do something like:

  struct pthread {
	  :
	long reserved;
  };

and then access sys_info via ((long *) tcb_pointer)[-1].  That way, no
matter what the alignment, you'll always access the right word and will
only use up an extra 8 bytes.

  >> That's not sufficient.  The offset must be the same across _all_ libcs,
  >> so that non-libc code can use the new syscall stubs as well.

  Jakub> I don't think it is a good idea to give access to glibc
  Jakub> internals (which these are) to outside code.  There is
  Jakub> syscall(3) function for a reason.

It's not glibc internals, it's ia64 linux abi.  I certainly do not
encourage the use of handcrafted syscall stubs, but sometimes, they're
needed.

  Jakub> Also, derefencing r13[-8] (or r13[8]) in various syscall stub
  Jakub> macros is not going to work if you run the program then
  Jakub> against older glibc and there won't be any symbol versioning
  Jakub> which would catch it up.

If someone chooses to use the new syscall stubs, they'll have to live
with that.

	--david


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