On Mon, 24 Feb 2020 11:42:23 +0100 Andreas Schwab <schwab@xxxxxxx> wrote: > On Feb 24 2020, Lukasz Majewski wrote: > > > On Mon, 24 Feb 2020 11:23:51 +0100 > > Andreas Schwab <schwab@xxxxxxx> 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 aren't? PLT avoidance is about internal references, and uses > >> a different name then the exported sybmol. > >> > > > > 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 symbols visible when I do want to use redirections. > > You cannot redirect to GLIBC_PRIVATE symbols, they are not suposed to > be used by public interfaces. All public interfaces need to use > official versioned symbols. > I've put those symbols to GLIBC_PRIVATE as up till now many more functions in glibc needs conversion to support 64 bit time. I need exported symbols to test if the redirection (and Y2038 safeness on ARM in general) works. I also do guess that when we will be heading to expose _TIME_BITS==64 to outside word I would need to add: GLIBC_2.3X { clock_settime64; } for clock_settime64 and then: #ifdef __USE_TIME_BITS64 # if defined(__REDIRECT_NTH) extern int __REDIRECT_NTH (clock_settime, (clockid_t __clock_id, const struct timespec *__tp), clock_settime64); # else # define clock_settime clock_settime64 # endif #endif Am I correct ? > Andreas. > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@xxxxxxx
Attachment:
pgpTRkTcEvYpE.pgp
Description: OpenPGP digital signature
_______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
