public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Carl Love <cel@us.ibm.com>
To: will schmidt <will_schmidt@vnet.ibm.com>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Cc: gdb-patches@sourceware.org, Rogerio Alves <rogealve@br.ibm.com>
Subject: Re: [PATCH] Powerpc: Add support for openat and fstatat syscalls
Date: Tue, 12 Oct 2021 12:13:43 -0700	[thread overview]
Message-ID: <9bf3148807544fd7b83ec9334e9c18cf7b9bee81.camel@us.ibm.com> (raw)
In-Reply-To: <ad0dbfa53146d7af40207e976aa3f2a3e70f9763.camel@vnet.ibm.com>

Will:


> > I changed the fstatat64 to newfstat.  I re-ran the regression tests
> > on
> > a Power 9 system.  The patch does seem to work correctly.  Don't
> > have
> > a
> > 32-bit system to verify on.
> 
> So.. the regression tests passed with both fstatat64 and newfstat ? 
> That suggests there is not a significant difference between the two
> syscalls, or this particular corner is not being tested.   
> 

It seemed weird to me that both work.  I too was a bit puzzled and
concerned by that.  So I did some more digging .... 

I found the following web page that gives the syscall numbers on a
number of platforms

https://marcin.juszkiewicz.com.pl/download/tables/syscalls.html

So as Ulrich said fstatat64 is listed for powerpc (32-bit) but not
supported for powerpc64.  The fstatat64 call maps to system call number
291.

Looking at newfstatat in the table, it is defined on powerpc64 but not
on powerpc (32-bit).  It also maps to system call number 291.

Clicking on newfstatat and fstatat64 in the left column takes us to the
same man page for both system call names.  

The man pages says is:  

"The fstatat() system call is a more general interface for accessing
file information which can still provide exactly the behavior of each
of stat(), lstat(), and fstat()."  

So, it says to me that calling newfstatat for both, as Ulrich said, is
fine.  I do think this is all rather convoluted.  I guess it is one of
those things that evolved over time into something more convoulted and
confusing then it should be.  

So as you said "...there is not a significant difference between the
two syscalls".  

                        Carl 


  reply	other threads:[~2021-10-12 19:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 20:59 Carl Love
2021-10-07 17:52 ` Ulrich Weigand
2021-10-07 19:43   ` Sergio Durigan Junior
     [not found] ` <OF499743BD.418B9A20-ONC1258767.0061CCF4-C1258767.006229AD@us.ibm.com>
2021-10-11 21:17   ` Carl Love
2021-10-11 21:57     ` will schmidt
2021-10-12 19:13       ` Carl Love [this message]
2021-10-13 13:08         ` Ulrich Weigand
     [not found]         ` <OF8D70D176.67629273-ONC125876D.00479F81-C125876D.004826BA@us.ibm.com>
2021-10-13 21:55           ` Carl Love
2021-10-14 11:21             ` Ulrich Weigand

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=9bf3148807544fd7b83ec9334e9c18cf7b9bee81.camel@us.ibm.com \
    --to=cel@us.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=rogealve@br.ibm.com \
    --cc=will_schmidt@vnet.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).