Re: Trouble executing example translator from Hurd Hacking Guide
Thanks Samuel, It's working now, with a few small tweaks. Both putting #define _FILE_OFFSET_BITS 64 and switching the offset type in the read function to loff_t caused the translator to output what appears to be the contents of some memory instead of a string of '1's. But compiling with -D_FILE_OFFSET_BITS=64 worked. There's also a small bug in the program itself. Instead of assigning the char '1' in the for loop, it's assigning the int 1, causing it to output the character with the ascii code 1. Samuel Thibault writes: > Samuel Thibault, le sam. 27 juil. 2019 11:09:56 +0200, a ecrit: >> The issue here is actually that the source code is missing >> >> #define _FILE_OFFSET_BITS 64 >> >> at the very top of the file. > > Or you can make the hooks use loff_t instead of off_t. > > Samuel -- Andrew Eggenberger
Re: Trouble executing example translator from Hurd Hacking Guide
Thank you. Yes, I misunderstood. All three methods work (independently) now. Samuel Thibault writes: > Hello, > > Andrew Eggenberger, le dim. 28 juil. 2019 04:21:21 -0500, a ecrit: >> It's working now, > > Good :) > >> Both putting #define _FILE_OFFSET_BITS 64 and switching the offset >> type in the read function to loff_t > > ? Only one of the two should be needed. Note that the #define needs to > be very first, before #includes, since it's driving what includes are > supposed to do. > >> There's also a small bug in the program itself. Instead of assigning >> the char '1' in the for loop, it's assigning the int 1, causing it to >> output the character with the ascii code 1. > > AIUI that was the purpose, but apparently it would be less surprising to > emit '1' chars, so I changed that too. > > Samuel -- Andrew Eggenberger
Re: Trouble executing example translator from Hurd Hacking Guide
Hello, Andrew Eggenberger, le dim. 28 juil. 2019 04:21:21 -0500, a ecrit: > It's working now, Good :) > Both putting #define _FILE_OFFSET_BITS 64 and switching the offset > type in the read function to loff_t ? Only one of the two should be needed. Note that the #define needs to be very first, before #includes, since it's driving what includes are supposed to do. > There's also a small bug in the program itself. Instead of assigning > the char '1' in the for loop, it's assigning the int 1, causing it to > output the character with the ascii code 1. AIUI that was the purpose, but apparently it would be less surprising to emit '1' chars, so I changed that too. Samuel
Shipping and including _S.h files? [Was: Trouble executing example translator from Hurd Hacking Guide]
Hello,
Samuel Thibault, le sam. 27 juil. 2019 11:32:44 +0200, a ecrit:
> Samuel Thibault, le sam. 27 juil. 2019 11:09:56 +0200, a ecrit:
> > The issue here is actually that the source code is missing
> >
> > #define _FILE_OFFSET_BITS 64
> >
> > at the very top of the file.
>
> Or you can make the hooks use loff_t instead of off_t.
Either way, we should make sure to have warnings when it's not done.
I'm thinking that hurd/{triv,disk,net}fs.h could at least include the
prototypes for io_read/write etc. (those RPCs which do depend on this)
to make sure these are properly set (since the off_t thing is very
subtle).
I'm however wondering why we don't just ship the _S.h files in
/usr/include/hurd/, and make {triv,disk,net}fs.h include them?
Translators in hurd/ do include them manually already probably to
catch such errors, but I'd say it's part of the lib{triv,disk,net}fs
interfaces so we should just make any user of them include it?
Samuel
Re: Trouble executing example translator from Hurd Hacking Guide
Samuel Thibault, le sam. 27 juil. 2019 11:09:56 +0200, a ecrit: > The issue here is actually that the source code is missing > > #define _FILE_OFFSET_BITS 64 > > at the very top of the file. Or you can make the hooks use loff_t instead of off_t. Samuel
Re: Trouble executing example translator from Hurd Hacking Guide
Hello, Andrew Eggenberger, le ven. 26 juil. 2019 20:36:20 -0500, a ecrit: > I've been trying to compile and run the trivfs example [1] in the Hurd > Hacking Guide. It compiles with the slightly amended command: > > gcc -g -o one -ltrivfs -lports Indeed, it is using a libports function and nowadays tools don't let that implicitly taken from libtrivfs. > mmap fails to allocate memory. When I checked the errno string, it said > there was an invalid argument. The mmap manual says MAP_SHARED or > MAP_PRIVATE need to appear in the flags argument (the fourth one). MAP_PRIVATE is actually #defined to 0, so it's not actually "mandatory". The idea here is that MAP_ANON means MAP_PRIVATE anyway, so people were not putting the latter. > I tried adding each and the error persisted. Another possible reason > for the error according to the man page is an amount that is too > high. I checked the variable and it is a large number, but I don't > know how to check to see how much is too much. Print it in hex: gdb> p/x amount 0x That is way too much (2^32-1) for the 32bit address space. That's where the problem comes from. The issue here is actually that the source code is missing #define _FILE_OFFSET_BITS 64 at the very top of the file. It seems that compatibility symbols have not been introduced, and thus your translator was using 32bit off_t while libtrivfs uses 64bit off_t. Recompile with that #define and it should work. I have updated the webpage, I guess that will show up after mirrors catch up. Samuel
