IRC channel logs

<diegonc>It's weird that newp is null given that GLIBC passes the address of a parameter

<almuhs>i suppose that might be this other https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/lseek.c;h=edc3a46506b7a65603dce5f408db8c3434b5e031;hb=HEAD

<almuhs>Because my code is 32-bit

<diegonc>yeah, but it just calls the 64 bit version

<almuhs>but my function is io_seek(), not lseek()

<almuhs>ok, now i see

<diegonc>io_seek is an RPC defined in hurd.git/hurd/io.defs, GLIBC calls that and translators based on libtrivfs provide an implementation

<almuhs>ok, i will check

<diegonc>which I guess is trivfs_S_io_seek

<almuhs>and, where is the definition?

<almuhs>io_seek() is called from trivfs_S_io_seek()

<diegonc>in your first link there's an implementation for io_seek

<almuhs>here? https://gitlab.com/AlmuHS/hurd-translator-in-rust/-/blob/main/Caesar_Encryption_Translator/Initial code/caesar.c

<diegonc>yes, but is called on the underlying node. i.e app (lseek) --> translator (trivfs_S_io_seek) --> ext2fs (?)

<almuhs>then would be recursive

<diegonc>no, because the target of the call is different

<diegonc>in one call the target is your translator and in the other it's ext2fs

<almuhs>ok

<diegonc>supposing ceasar is mount on top of a file in your main partition

<almuhs>yes, it is

<almuhs>it's execute like "settrans -gac dest_file caesar origin_file"

<diegonc>the chain could be longer (like when isofs is used on a ftpfs)

<almuhs>and, when you shows dest_file, then caesar is executed and the file shows the crypted text

<almuhs>the backtrack is long

<almuhs> https://paste.debian.net/1393863/

<diegonc>hmm I wonder what's the unknown in 18, hopefully it's not relevant

<diegonc>main.rs#L237 point to SEEK_CUR, maybe po is what's null

<almuhs>po points to cred->po

<almuhs> po = (*cred).po;

<almuhs>seems that the resource is not created correctly. Because, after load the translator, cat doesn't recognize the file

<almuhs>pruebas@debian-hurd:~$ cat crypto

<almuhs>cat: crypto: Argumento inválido

<almuhs>and less show the backtrace

<almuhs> https://paste.debian.net/1394093/

<almuhs>always the failure is here: (*newp) = offset;

<almuhs>in trivfs_S_io_seek()

<diegonc>ah that backtrace actually points to line 239

<diegonc>yep

<almuhs>just a few after calls to bindings::ports_manage_port_operations_one_thread ((*cntl).pi.bucket, bindings::trivfs_demuxer, 0);

<almuhs>from the main()

<almuhs>but there are two "unknown" in the middle

<diegonc>almuhs: weird, it works for me

<diegonc>I'm on amd64 though

<diegonc>cargo build complained about usage of u128 in various places (and claimed it's not FFI safe or something like that)

<diegonc>demo@debian:~/dev/almu/hurd-translator-in-rust/Caesar_Encryption_Translator/caesar-rust$ echo "Hi!" > test && settrans -gac enc target/debug/caesar test && cat test

<diegonc>Hi!

<diegonc>demo@debian:~/dev/almu/hurd-translator-in-rust/Caesar_Encryption_Translator/caesar-rust$ echo "Hi!" > test && settrans -gac enc target/debug/caesar test && cat enc

<diegonc>Uv!

<almuhs>yes, but i think that is unused here

<almuhs>i go to test your commands

<almuhs>the first command returns "translator dead"

<almuhs>the second same

<almuhs>ruebas@debian-hurd:~$ echo "hi" > test && settrans -gac enc caesar-rust-bin && cat enc

<almuhs>settrans: caesar-rust-bin: Translator died

<almuhs>ok, it lacks arguments in settrans

<almuhs>pruebas@debian-hurd:~$ echo "hi" > test && settrans -gac enc caesar-rust-bin test && cat enc

<almuhs>cat: enc: Invalid argument

<almuhs>and "less enc" shows the backtrace

<almuhs>diegonc: do you get a different return than me?

<almuhs>i'm testing in the i686 version

<diegonc>everything works here (cat or less). there must be some problem with type sizes in i686

<diegonc>I'll switch to the i686 VM to try it out

<almuhs>maybe Rust are translating int and unsigned to 32-bit length versions

<almuhs>in i686 int must be 16-bit lenght

<almuhs>same with unsigned, and related

<diegonc>short is 16-bit

<diegonc>int should be 32 I beleive

<almuhs>in hurd i don't know, but usually in 32-bit architectures, int are 16-bit length

<almuhs>try in the i686 VM, and if fails, then i check the sizes

<diegonc>I'm downloading the code on it :)

<almuhs>ok

<almuhs>i'm installing the x86_64's hurd

<almuhs>argg... my Debian GNU/Hurd x86_64 installation failed. I think that my img is so little

<almuhs>restarting installation with a bigger image

<diegonc>I'm afraid I got an old image. how do I get the pub keys for apt? ( NO_PUBKEY 3AF65F93D6FBC5B9 )

<almuhs>i usually mark as trusted=yes

<almuhs>deb [check-valid-until=no trusted=yes] http:// ...

<diegonc>I have it like that, but some key was expired and failing

<diegonc>I think I'm gonna start over from the last image

<almuhs>yes, it's better

<almuhs>i've just installed the amd64 image. Now upgrading. i can't install git

<almuhs>dependencies error

<almuhs>installing rustc

<almuhs>ok. I downloaded my code from tar, and i tested it in amd64. It doesn't crash, but neither crypt

<almuhs>but it's a progress. I have to check data types

<diegonc>that's weird, catted the correct file?

<almuhs>yes

<almuhs>but have the same text than the original

<almuhs>maybe the conditions of caesar() are never true

<almuhs>ok, in the second attempt worked

<almuhs>it works

<diegonc>\o/

<almuhs>so i'm replacing the integers to 32-bit versions

<almuhs>maybe the origin of the problem is in type sizes

<almuhs>the bindings file was generated over a linux, in 64-bit, so probably takes the sizes from there

<almuhs>after some size fix, remains work in amd64. Now I have to test in i686

<almuhs>in i686 the problem remains

<diegonc>pub type __loff_t = __off64_t

<diegonc>I think this is the problem. by having a bigger loff_t parameters are shifted and newp gets the higher order bits which could be 0

<diegonc>pub fn __io_seek( io_object: io_t, offset: __loff_t, whence: ::std::os::raw::c_int, newp: *mut __loff_t, ) -> kern_return_t;

<diegonc>maybe whence is pushed to the position of newp

<diegonc>well, it wasn't just that change :(

<almuhs>diegonc: yes, i found the same. I put as longlong, and now it works in i686. I go to check in amd64

<almuhs>oh, now breaks in amd64

<almuhs>solved: I applied rules to define differents size for loff_t and mach_port_name_t depending if arch is 32-bit or 64-bit based

<damo22>shouldnt the system headers provide that?

<damo22>or the rustc targe

<damo22>t

<almuhs>the rustc target, but it doesn't solve the problem fine, so I've patched manually

<damo22>are you cross compiling from linux?

<almuhs>no

<damo22>-D_FILE_OFFSET_BITS=64 ?

<damo22>we usually need that on i686

<almuhs>then i will patch it too

<damo22>it might fix your problem entirely

<damo22>no need to patch anything

<almuhs>i fixed most applying c standard types

<almuhs>but some of them are not solved properly

<damo22>you need to use the hurd types

<damo22>if its not working, its because you are missing some #define

<almuhs>yes, i use the hurd types, but some blocks use standard types

<almuhs>and some hurd types are alias to standard c-types

<damo22>if you use standard types, you will have problems

<damo22>because some types are dynamic depending on i686/x86_64

<damo22>but the system headers have it all defined

<almuhs>yes. bindgen translated the dynamic types to fixed-sizes, based in x86_64

<damo22>rustc should already know about them

<damo22>but even so, some are configurable behind defines, like _FILE_OFFSET_BITS

<almuhs>i don't find this define in my bindings file

<damo22>check hurd translators to see what defines are being used to compile them

<almuhs>ok

<damo22>rust-libc$ git grep _FILE_OFFSET_BITS

<damo22>src/unix/hurd/mod.rs: b"-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64\0";

<damo22>pub const __ILP32_OFFBIG_CFLAGS: &'static [u8; 43usize] =

<damo22> b"-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64\0";

<almuhs>maybe are you checking the hurd-amd64 target?

<AlmuHS>i go to sleep. Tomorrow i will continue checking the types

IRC channel logs

2025-08-31.log