IRC channel logs

<Pellescours>damo22: I made progress on building tools of netbsd

<Pellescours>I fixed the root cause that was making code entering in cpp_errno_filename (which segfault)

<Pellescours>the root cause is because read fails and should not. I’m trying to understand and reproduce it in a simple example

<damo22>ok

<damo22>that's good

<Pellescours>my fix was (just before the read) close and reopen the file. I’m trying to know if it’s because of the O_NONBLOCK in open that read fails

<Pellescours>because this fix is really hacky

<damo22>maybe remove the O_NONBLOCK

<damo22>idk

***Server sets mode: +nt

<Pellescours>WTF, I found the reason

<Pellescours>it’s because of a ternary check to decide of flag to set or not. If I remove the ternary check it work

<Pellescours> http://paste.debian.net/1194352/

<Pellescours>here how to reproduce

<Pellescours>that’s really strange

<Pellescours>Ah, I found:

<Pellescours>no not found

<Pellescours>(gdb)

<Pellescours>22 int a = O_RDONLY | O_NOCTTY | (val != NULL) ? O_NONBLOCK : 0;

<Pellescours>(gdb)

<Pellescours>23 int b = O_RDONLY | O_NOCTTY | O_NONBLOCK;

<Pellescours>(gdb)

<Pellescours>24 int c = O_RDONLY | O_NOCTTY | 0;

<Pellescours>(gdb)

<Pellescours>25 int file = open(filename, O_RDONLY | O_NOCTTY | (val != NULL) ? O_NONBLOCK : 0, 0666);

<Pellescours>(gdb) p a

<Pellescours>$1 = 8

<Pellescours>(gdb) p b

<Pellescours>$2 = 9

<Pellescours>(gdb) p

<Pellescours>(gdb) p c

<Pellescours>$3 = 1

<youpi>put parentheses

<youpi>?: is terribly low priority

<youpi>so | goes into the parameter of ?

<youpi>instead of getting combined with the ?: result

<Pellescours>that’s it

<Pellescours>I send a patch to NetBSD to have this fixed

<Pellescours>good night, and thank you youpi

<Pellescours> https://github.com/NetBSD/src/blob/trunk/external/gpl3/gcc/dist/libcpp/files.c#L235 actually gcc seems to have the same problem (I don’t ko

<Pellescours>I don’t know why problem did not appear before (gcc is built on hurd so it should have trigger this problem)

<Pellescours>I know. It’s because on gcc they don’t have this ternary operation

<dogtooth>hello

<dogtooth>I'm interested in hanging around and doing Hurd stuff. I'm still pretty new so I'll just try to chase a bug here or there and ask questions when I get stuck.

<dogtooth>I was going to see about GSoC but I understand the deadline has already passed by.

<dogtooth>The Hurd is very cool, I'm enjoying playing with it in qemu right now

***rekado_ is now known as rekado

<gnu_srs1>damo22: Not much is happening recently. Any ideas on how to make at least the rumpdisk boot startup/shutdown working?

<youpi>things did happen recently

<youpi>see the mails on bug-hurd

<damo22>dogtooth: thats cool, welcome

<damo22>i cant do much work on hurd this week, i am moving house

<damo22>that said, we're getting closer to fixing the stat issue, and that will help shutdown/startup

<Pellescours>now compile blocks with CLOCK_REALTIME not defined :D

<youpi>that's a missing #include or #define

<youpi>we do have that macro

<Pellescours>it’s because the corresponding include is done only if __linux__ is defined

<Pellescours>it’s __gnu__ for hurd?

<youpi>it's __GNU__

<youpi>what include ?

<youpi>that's just completely posix

<youpi>there is no reason to use ifdefs for such thing

<Pellescours>I don’t know why but there is an ifdef

<youpi>what include?

<Pellescours> https://github.com/NetBSD/src/blob/trunk/external/cddl/osnet/sys/sys/time.h#L100

<youpi>really there is no reason to have an ifdef, time.h is in posix since ages

<youpi>possibly that conflicts with definitions above, but a #else would be enough

<Pellescours>that’s NetBSD codebase

<youpi>yes but you can use a #else

<Pellescours>I did the change and it worked

<Pellescours>I built tools successfully

<Pellescours>AND I built Netbsd kernels \o/

<Pellescours>so except the two tools issues (patches are sent) we should no encounter problem for building rump

<dogtooth>hey guys, anyone still around?

<Pellescours>yes dogtooth

<dogtooth>very cool @Pellescours, just trying to get a sense of when this chat is active

<ThinkT510>dogtooth: there is a link in the /topic for channel logs too

<dogtooth>ah, thank you ThinkT510!

***Emulatorman_ is now known as Emulatorman

IRC channel logs

2021-04-20.log