Hi Joseph,
> On Wed, 26 Feb 2020, Lukasz Majewski wrote:
>
> > > > hidden_def (__mq_timedsend)
> > > > weak_alias (__mq_timedsend, mq_timedsend) [**]
> > > > hidden_weak (mq_timedsend)
> > >
> > > If you have lib_hidden_weak note you also need a
> > > corresponding lib_hidden_proto, for the
On Wed, 26 Feb 2020, Lukasz Majewski wrote:
> > > hidden_def (__mq_timedsend)
> > > weak_alias (__mq_timedsend, mq_timedsend) [**]
> > > hidden_weak (mq_timedsend)
> >
> > If you have lib_hidden_weak note you also need a corresponding
> > lib_hidden_proto, for the name of the weak alias. But
Hi Joseph,
> On Tue, 25 Feb 2020, Lukasz Majewski wrote:
>
> > Lets consider for example __mq_timedsend_time64.
> >
> > With lib_hidden_def/proto kept (NOT removed as in [1]):
> > GDB:
> > __GI___mq_timedsend_time64 [*]
> >
> > (No build errors, linking with test setup works as expected).
On Tue, 25 Feb 2020, Lukasz Majewski wrote:
> Lets consider for example __mq_timedsend_time64.
>
> With lib_hidden_def/proto kept (NOT removed as in [1]):
> GDB:
> __GI___mq_timedsend_time64 [*]
>
> (No build errors, linking with test setup works as expected).
What is the actual testcase,
Hi Joseph,
Thanks for the detailed explanation.
> On Mon, 24 Feb 2020, Lukasz Majewski wrote:
>
> > I'm probably not aware of something - but as done in the following
> > patch:
> >
> > https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
> >
> > I do need
On Mon, Feb 24, 2020 at 10:01 AM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski
> > wrote:
> > which seems a bug in the test suite. The other two get a segfault
> > that I have not debugged, but I guess this is likely a problem in your
> > patches. Have you seen the
On Mon, 24 Feb 2020, Lukasz Majewski wrote:
> I'm probably not aware of something - but as done in the following
> patch:
>
> https://github.com/lmajewski/y2038_glibc/commit/c96eeb73175961c4ac80fdd3b6adc132805387c9
>
> I do need to remove librt_hidden_proto / librt_hidden_def to have
> proper
Dear All,
> On Mon, 24 Feb 2020 11:42:23 +0100
> Andreas Schwab wrote:
>
> > On Feb 24 2020, Lukasz Majewski wrote:
> >
> > > On Mon, 24 Feb 2020 11:23:51 +0100
> > > Andreas Schwab wrote:
> > >
> > >> On Feb 24 2020, Lukasz Majewski wrote:
> > >>
> > >> > If I add those functions
On Mon, 24 Feb 2020 11:42:23 +0100
Andreas Schwab wrote:
> On Feb 24 2020, Lukasz Majewski wrote:
>
> > On Mon, 24 Feb 2020 11:23:51 +0100
> > Andreas Schwab wrote:
> >
> >> On Feb 24 2020, Lukasz Majewski wrote:
> >>
> >> > If I add those functions as hidden_alias then those would be
>
On Feb 24 2020, Lukasz Majewski wrote:
> On Mon, 24 Feb 2020 11:23:51 +0100
> Andreas Schwab wrote:
>
>> On Feb 24 2020, Lukasz Majewski wrote:
>>
>> > If I add those functions as hidden_alias then those would be
>> > accessible inside glibc without PLT, but will not be exported (and
>> >
On Mon, 24 Feb 2020 11:23:51 +0100
Andreas Schwab wrote:
> On Feb 24 2020, Lukasz Majewski wrote:
>
> > If I add those functions as hidden_alias then those would be
> > accessible inside glibc without PLT, but will not be exported (and
> > redirection for Y2038 will not work).
>
> They
On Feb 24 2020, Lukasz Majewski wrote:
> If I add those functions as hidden_alias then those would be accessible
> inside glibc without PLT, but will not be exported (and redirection for
> Y2038 will not work).
They aren't? PLT avoidance is about internal references, and uses a
different name
Hi Andreas,
> On Feb 24 2020, Lukasz Majewski wrote:
>
> >> elf/check-localplt complains about the newly added symbols
> >>
> >> Extra PLT reference: libc.so: __lutimes64
> >> Extra PLT reference: libc.so: __wait4_time64
> >> Extra PLT reference: libc.so: __setitimer64
> >> Extra PLT reference:
On Feb 24 2020, Lukasz Majewski wrote:
>> elf/check-localplt complains about the newly added symbols
>>
>> Extra PLT reference: libc.so: __lutimes64
>> Extra PLT reference: libc.so: __wait4_time64
>> Extra PLT reference: libc.so: __setitimer64
>> Extra PLT reference: libc.so: __utime64
>> Extra
Hi Arnd,
> On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski
> wrote:
>
> > [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge
>
> I tried packaging this into a .deb package for use with rebootstrap,
> but ran into a couple of test failures from glibc itself, when
> testing the
On 20-02-20, 15:44, Arnd Bergmann wrote:
> On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote:
> > > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski
> > > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> > > There is also some work
> > > in Linaro to ensure that LTP tests the
On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski wrote:
> [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge
I tried packaging this into a .deb package for use with rebootstrap, but
ran into a couple of test failures from glibc itself, when testing the i386
version while running
On Thu, Feb 20, 2020 at 4:37 AM Arnd Bergmann wrote:
>
> On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski wrote:
> > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> > >
> > > Would it be possible to take a snapshot of your glibc tree
> >
> > The description of the status of Y2038
Hi Arnd,
> On Thu, Feb 20, 2020 at 4:42 PM Lukasz Majewski wrote:
> > > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski
> > > wrote:
>
> >
> > I do see two approaches here:
> >
> > 1. In glibc:
> >
> > When -D_TIME_BITS=64 is set - redirections are enabled for syscall
> > wrappers; for
Hi Arnd,
On Thu, Feb 20, 2020 at 09:31:32AM +0100, Arnd Bergmann wrote:
> > > How do I build a latest RISCV 32-bit kernel + userland - do you have
> > > a buildroot branch somewhere that I can build / test with qemu ?
> >
> > Maybe a bit off topic - there is such QEMU and Yocto/OE based test
> >
On Thu, Feb 20, 2020 at 4:42 PM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote:
>
> I do see two approaches here:
>
> 1. In glibc:
>
> When -D_TIME_BITS=64 is set - redirections are enabled for syscall
> wrappers; for example __clock_settime64 is used instead
Hi Arnd,
> On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote:
> > > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski
> > > wrote:
> > > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> > > > > Are there any glibc issues that prevent it
> > > > > from working correctly,
> > > >
>
On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski
> > wrote:
> > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> > > > Are there any glibc issues that prevent it from working
> > > > correctly,
> > >
> > > I think that the glibc
On Thu, 20 Feb 2020, Arnd Bergmann wrote:
> But surely that structure layout would be the same on ARM and ARC
> as well as all other 32-bit architectures with _TIME_BITS=64, right?
Yes.
> What's wrong with having a single implementation for the most
> recent set of stat syscalls, with the older
Hi Arnd,
> On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski
> wrote:
> > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> > >
> > > Would it be possible to take a snapshot of your glibc tree
> >
> > The description of the status of Y2038 supporting glibc on ARM 32
> > can be found here
On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> >
> > Would it be possible to take a snapshot of your glibc tree
>
> The description of the status of Y2038 supporting glibc on ARM 32 can
> be found here [1].
>
> The most recent
Hi Arnd, Joseph,
> On Thu, Feb 20, 2020 at 1:46 AM Joseph Myers
> wrote:
> >
> > On Thu, 20 Feb 2020, Vineet Gupta wrote:
> >
> > > The first 4 will need more work as sym aliasing like
> > > strong_alias (__xstat64, __xstat)
> > >
> > > will be needed in those ARM files (which in turn
Hi Arnd,
> On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> wrote:
> > > On 2/14/20 2:39 PM, Alistair Francis wrote:
> > > > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers
> > > An the reason this all works on RISCV is that your kernel doesn't
> > > define __ARCH_WANT_STAT64 -> lacks
On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski wrote:
> > On 2/14/20 2:39 PM, Alistair Francis wrote:
> > > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers
> > An the reason this all works on RISCV is that your kernel doesn't
> > define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses
On Thu, Feb 20, 2020 at 1:46 AM Joseph Myers wrote:
>
> On Thu, 20 Feb 2020, Vineet Gupta wrote:
>
> > The first 4 will need more work as sym aliasing like
> > strong_alias (__xstat64, __xstat)
> >
> > will be needed in those ARM files (which in turn use i386).
>
> The situation for Arm is
On Thu, 20 Feb 2020, Vineet Gupta wrote:
> The first 4 will need more work as sym aliasing like
> strong_alias (__xstat64, __xstat)
>
> will be needed in those ARM files (which in turn use i386).
The situation for Arm is fundamentally different from that for ARC.
For ARC, you only need a
Hi Lukasz,
On 2/19/20 3:18 PM, Lukasz Majewski wrote:
> Please keep in mind that there are some architectures (like 32 bit
> ARM), which are NOT using asm-generic API.
Right understand that.
> Those archs also require support for 64 bit time. That is why Alistair
> put the [sg]etitimer
Hi Vineet,
> On 2/19/20 12:30 AM, Andreas Schwab wrote:
> > On Feb 19 2020, Vineet Gupta wrote:
> >
> >> On 2/18/20 5:03 PM, Alistair Francis wrote:
> > +#define STAT_IS_KERNEL_STAT 1
> Isn't this irrelevant: seems to be only used for legacy
> __NR_stat/__NR_stat64 syscalls
Hi Vineet,
> Hi Alistair, Arnd
>
> On 2/14/20 2:39 PM, Alistair Francis wrote:
> > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers
> > wrote:
> >> On Tue, 11 Feb 2020, Alistair Francis wrote:
> >>
> > diff --git a/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> >
Hi Joseph, Vineet,
> On Tue, 18 Feb 2020, Vineet Gupta wrote:
>
> > An the reason this all works on RISCV is that your kernel doesn't
> > define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses
> > the statx call which does itemized copy and would work fine when
> > copying from
On 2/19/20 12:30 AM, Andreas Schwab wrote:
> On Feb 19 2020, Vineet Gupta wrote:
>
>> On 2/18/20 5:03 PM, Alistair Francis wrote:
> +#define STAT_IS_KERNEL_STAT 1
Isn't this irrelevant: seems to be only used for legacy
__NR_stat/__NR_stat64
syscalls based__xstat()/__xstat64().
On Feb 19 2020, Vineet Gupta wrote:
> On 2/18/20 5:03 PM, Alistair Francis wrote:
+#define STAT_IS_KERNEL_STAT 1
>>> Isn't this irrelevant: seems to be only used for legacy
>>> __NR_stat/__NR_stat64
>>> syscalls based__xstat()/__xstat64().
>> Is it? It seems to be used in a few places,
On 2/18/20 5:03 PM, Alistair Francis wrote:
>>> +#define STAT_IS_KERNEL_STAT 1
>> Isn't this irrelevant: seems to be only used for legacy __NR_stat/__NR_stat64
>> syscalls based__xstat()/__xstat64().
> Is it? It seems to be used in a few places, including:
>
> sysdeps/unix/sysv/linux/fxstatat.c
>
On Tue, Feb 18, 2020 at 4:57 PM Vineet Gupta wrote:
>
> Hi Alistair,
>
> On 1/12/20 2:33 AM, Alistair Francis wrote:
> > diff --git a/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
> > b/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
>
> [snip]...
>
> > +#define STAT_IS_KERNEL_STAT 1
>
> Isn't this
Hi Alistair,
On 1/12/20 2:33 AM, Alistair Francis wrote:
> diff --git a/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
> b/sysdeps/unix/sysv/linux/riscv/kernel_stat.h
[snip]...
> +#define STAT_IS_KERNEL_STAT 1
Isn't this irrelevant: seems to be only used for legacy __NR_stat/__NR_stat64
syscalls
On Tue, 18 Feb 2020, Vineet Gupta wrote:
> An the reason this all works on RISCV is that your kernel doesn't define
> __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses the statx call
> which
> does itemized copy and would work fine when copying from 32-bits time (in
> kernel)
> to
Hi Alistair, Arnd
On 2/14/20 2:39 PM, Alistair Francis wrote:
> On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers wrote:
>> On Tue, 11 Feb 2020, Alistair Francis wrote:
>>
> diff --git a/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
>
On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers wrote:
>
> On Tue, 11 Feb 2020, Alistair Francis wrote:
>
> > > > diff --git a/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> > > > b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> > > > new file mode 100644
> > > > index 00..0da3bdeb5d
>
On Wed, Feb 12, 2020 at 2:42 AM Vineet Gupta wrote:
> On 2/11/20 4:14 PM, Alistair Francis wrote:
> > On Tue, Feb 11, 2020 at 4:14 PM Vineet Gupta wrote:
>
> >>> +/* Same for ino_t and ino64_t. */
> >>> +# define __INO_T_MATCHES_INO64_T 1
>
> I'm surprised that ARC port doesn't define this in
On Tue, Feb 11, 2020 at 4:14 PM Vineet Gupta wrote:
>
> Hi Alistair,
Hi Vineet,
>
> On 1/12/20 2:33 AM, Alistair Francis wrote:
> > Using the original glibc headers under bits/ let's make small
> > modifications to use 64-bit time_t and off_t for both RV32 and RV64.
> >
> > For the typesizes.h,
Hi Alistair,
On 1/12/20 2:33 AM, Alistair Francis wrote:
> Using the original glibc headers under bits/ let's make small
> modifications to use 64-bit time_t and off_t for both RV32 and RV64.
>
> For the typesizes.h, here are justifications for the changes from the
> generic version (based on
46 matches
Mail list logo
