glibc 2.42 changed the definitions of baud rate constants (B50, B75, ..., B9600, B57600, ...)

[de-vri-es]

In glibc 2.41 and before, baud rate constants like B50, B75, ..., B9600, B57600, B115200, ... were enum-like values. B50 was 1, B75 was 2, etc.

In glibc 2.42 they have been redefined. B50 is now just 50, and B75 is now just 75. Additionally, the tcset{i,o,}speed and tcget{i,o,}speed functions are adjusted to deal with this internally (the kernel struct going to the ioctl still needs the legacy values, or a custom baud rate with BOTHER).

The old baud rate constants are still available as __B50, __B75, ...

https://inbox.sourceware.org/libc-announce/5906001.DvuYhMxLoT@pinacolada/T/#u

• On Linux, the <termios.h> interface now supports arbitrary baud rates; speed_t is redefined to simply be the baud rate specified as an unsigned int, which matches the kernel interface.

So.. is there a clean way to deal with this in the libc crate? The only portable thing for an application to do now is to manually do the TC{G,S}ETS2 ioctl and completely ignore the baud rate constants.

[devnexen]

Pb with glibc version detection, it can be done at runtime only, ie gnu_get_libc_version() (or directly __libc_version symbol), not too great neither since it s a string.

[hpax]

See also discussion at: nix-rust/nix#2672

[de-vri-es]

Maybe explicitly linking to an old version of the cf{g,s}et{i,o,}speed functions that support the old baud rate constants will work for now? In the future, when glibc 2.42 is widespread enough, the constants can be updated and the functions can be switched to the new ones.

I guess the only question is: which version should we use now? :]

objdump -T libc.so.6 | grep cfsetispeed
000000000010eea0 g    DF .text	000000000000002a  GLIBC_2.42  cfsetispeed
000000000016d0f0 g    DF .text	0000000000000054 (GLIBC_2.2.5) cfsetispeed

I guess the GLIBC_2.2.25 version.

[hpax]

That would be a very poor solution, and will make users do what they have done in C code, poorly, for a long time now: invoke ioctl() directly, usually incorrectly.

See my notes in the other linked thread.

The legacy version number varies depending on architecture; also, on MIPS and SPARC the tcsetattr() and tcgetattr() symbols are also versioned, as the format of struct termios has changed.

There are also the new cfget/setbaud() interfaces. If I'm not entirely mistaken, you might be able to do a weak undefined symbol to pick them up if available.

Finally, here is a trick to probe at initialization time: create a dummy struct termios, and call something like cfsetospeed(&dummy_termios, 0x3fffffff) – if it succeeds, you are using the new glibc (in fact, any constant greater than 0x100f should fail on the old system.) This will not cause any system calls.

You do know that the legacy baud rates constants, as well as struct termios format, are architecture-dependent, right?!

[de-vri-es]

That would be a very poor solution, and will make users do what they have done in C code, poorly, for a long time now: invoke ioctl() directly, usually incorrectly.

In Rust, people mostly don't use the libc crate directly. This is mostly a problem for library authors. Those already have to deal with the mess of serial ports, and they can not rely on glibc 2.42 being available. Not yet anyway.

The legacy version number varies depending on architecture; also, on MIPS and SPARC the tcsetattr() and tcgetattr() symbols are also versioned, as the format of struct termios has changed.

Thanks. And yeah. I did just figure out that the version symbols are architecture specific when trying to figure out the authoritative source for the right number (x86_64, aarch64).

Finally, here is a trick to probe at initialization time: create an empty struct termios, and call something like cfsetospeed(&dummy_termios, 0x40000000) – of of succeeds, you are using the new glibc.

Sadly, this will not be usable to change the actual value of the baud rate constants. This can only be done at build time because they are constants.

You do know that the legacy baud rates constants, as well as struct termios format, are architecture-dependent, right?!

I'm sure this is well intended, but I would appreciate it if you phrased a bit less aggressively. There's nothing new about that, it has already been the case before glibc 2.42.

Anyway, when trying to use the old symbols from pre-2.42, I already run into the issue that the auto generated tests will fail because they will still use the latest version. So now I think the best thing to do is just to do a build time check which glibc is being used, base the value of the baud rate constants on that, and fail to link at runtime if glibc 2.42 is not available.

[de-vri-es]

I also think it would be good if the libc crate uses versioned symbols correctly for glibc, but that will be a major overhaul.

[hpax]

That is consistent with glibc policy (you have to build and link against the headers and the .so file from the oldest version of glibc you want to run against.)

Apologies if I'm a bit snippy about this; I have just seen a lot of ABI abuse recently.

[de-vri-es]

No problem, thanks for the useful insights and information :)

[hpax]

As far as I can tell, it looks like the immediate consumer is the "unix" crate... which presumably should then get pulled by someone else...

[tgross35]

I'm trying to understand the exact situation here given it is evolving, but is there a specific symbol version that we would be able to link and continue using the old (octal) constants? If so, I think that would be the best solution here.

I also think it would be good if the libc crate uses versioned symbols correctly for glibc, but that will be a major overhaul.

We don't have a general mechanism for link-time symbol versioning as we haven't really needed it, but we can specify a version on a case-by-case basis. Currently there isn't anywhere this is used for glibc, but it is for some other platforms https://github.com/search?q=repo%3Arust-lang%2Flibc%20%2Flink_name.*%40%2F&type=code.

[de-vri-es]

I'm trying to understand the exact situation here given it is evolving, but is there a specific symbol version that we would be able to link and continue using the old (octal) constants? If so, I think that would be the best solution here.

There are specific versions, but it's architecture specific which version that is. Personally I'm in no mood to figure out the correct versions for each architecture and move the functions into the architecture specific submodules. And adjust the tests for each architecture.

If this is the desired solution, I understand, but I don't have the time to do it.

However, if we do, the behavior of the libc crate will not match the documentation of glibc. Since the libc crate does not come with it's own documentation, I also think this also somewhat confusing.

Lastly, if we stick with the pre 2.42 versions, then it is not possible to set custom baud rates on serial ports through libc. The only possibility is to bypass libc and do raw ioctls. People will likley mix raw ioctls with using libc APIS (I did), and that will lead to undefined behaviour.

I also think it would be good if the libc crate uses versioned symbols correctly for glibc, but that will be a major overhaul.

We don't have a general mechanism for link-time symbol versioning as we haven't really needed it, but we can specify a version on a case-by-case basis. Currently there isn't anywhere this is used for glibc, but it is for some other platforms https://github.com/search?q=repo%3Arust-lang%2Flibc%20%2Flink_name.*%40%2F&type=code.

Doing this case-by-case can lead to undefined behaviour: libc is upgraded, a rust program compiles with a new glibc, it uses new versions of symbols that have not explicitly been pinned to a version. However, constants and struct layouts in the libc crate have not been updated to match the ABI change. (This is exactly what happened to serial2, fixed here.)