#2 Please identify versions of gcc etc. you are working with

[Ed Reed]

Hi - glad to see you doing this work.

Could you give us what version of gcc you're using? Some things like (as you point out in the source) the call to x86.get_pc_thunk.ax are "very compiler dependent", and that symbol doesn't appear to be in my gcc 4.8.5 version. So, rather than begin a binary search of versions, I thought I'd ask.

And while you're at it, if you identified the kernel version you're working with, it would help nail down things like VFS_CAP_REVISION_3, which my SUSE Leap 42.3 (Linux 4.4.76-1-default) does't know about. I don't object to getting a later version, but would like to know what you're using.

Thanks,
Ed

[Russell Stuart]

The information you are after is already available thanks to Debian's reproducable builds effort. Ibcs-us_4.1.4-1_amd64.buildinfo in the Files area contains everything you need to know to get a bit for bit identical set of binaries, and naturally that includes the version of gcc (it's 6.3.0), and all C development headers.

Ibcs-us does not use the kernel headers. They define the kernel's internal API, and ibcs-us being a user space program uses the kernel's user space API (ie the syscalls). This is a good thing as while the kernel internal API changes almost as fast as colours in GUI fashions, the syscall API ibcs-us uses has been rock solid since 2.6. Thus the only kernel headers ibcs-us are those that define that API, which on Debian are provided by the package linux-libc-dev:i386 (ibcs-us being a 32 bit program).

What you are tripping over with VFS_CAP_REVISION_3 is something different. Ibcs-us doesn't use VFS_CAP_REVISION_3. It will be glibc headers that are using it, which is doubly annoying because ibcs-us goes out of its way to avoid using most of the stuff defined by the glibc headers. ("Most" because there are #defines the C standard requires the compiler to in standard headers, such as ptrdiff_t. They are part of the C language, not POSIX nor the OS API.) Ibcs-us avoids the glibc definition of things by either using the header files in linux-libc-dev directly, or where that is not possible (or I could not figure out how to do it) by setting special #define's that prevent glibc's C headers from defining things. This is where the rot sets in, as the glibc maintainers appear to regard those #define's as private to glibc itself and thus feel free to change them at will. What is happening in your case is they are different between the version you are using and the one I used, and some unwanted parts of glibc's headers are being compiled in. That seems like it should be mostly harmless, but instead it seems to cause the sort of problem you are seeing.

The upshot of all that is it's not they kernel headers that are causing you problems. It's the version of glibc headers you are using, and the version of the linux-libc-dev (they are intricately intertwined).

[Ed Reed]

That’s an very useful explanation. Thanks. I’ll look at the Debian build info, and use judgement as to how to resolve compilation issues with what I’m doing.

Any guidance on the GCC x86.get_pc_thunk.ax ask reference? Looks like it’s just capturing the function ID from the lcall. If so, I’ll work something out or uprev the gcc I’m using.

In the long term, I plan to port this to our own os using non GCC compiler tools, so I’ll be coming up with an alternative way to access tha information anyway.

Again, thanks for your work.

——————
Ed Reed

On Oct 6, 2019, at 09:42, Russell Stuart rstuart@users.sourceforge.net wrote:


The information you are after is already available thanks to Debian's reproducable builds effort. Ibcs-us_4.1.4-1_amd64.buildinfo in the Files area contains everything you need to know to get a bit for bit identical set of binaries, and naturally that includes the version of gcc (it's 6.3.0), and all C development headers.

Ibcs-us does not use the kernel headers. They define the kernel's internal API, and ibcs-us being a user space program uses the kernel's user space API (ie the syscalls). This is a good thing as while the kernel internal API changes almost as fast as colours in GUI fashions, the syscall API ibcs-us uses has been rock solid since 2.6. Thus the only kernel headers ibcs-us are those that define that API, which on Debian are provided by the package linux-libc-dev:i386 (ibcs-us being a 32 bit program).

What you are tripping over with VFS_CAP_REVISION_3 is something different. Ibcs-us doesn't use VFS_CAP_REVISION_3. It will be glibc headers that are using it, which is doubly annoying because ibcs-us goes out of its way to avoid using most of the stuff defined by the glibc headers. ("Most" because there are #defines the C standard requires the compiler to in standard headers, such as ptrdiff_t. They are part of the C language, not POSIX nor the OS API.) Ibcs-us avoids the glibc definition of things by either using the header files in linux-libc-dev directly, or where that is not possible (or I could not figure out how to do it) by setting special #define's that prevent glibc's C headers from defining things. This is where the rot sets in, as the glibc maintainers appear to regard those #define's as private to glibc itself and thus feel free to change them at will. What is happening in your case they are different between the version you are using and the one I used, and some unwanted part of glibc's headers are being compiled in. That seems like it should be mostly harmless, but instead it seems to cause the sort of problem you are seeing.

The upshot of all that is it's not they kernel headers that are causing you problems. It's the version of glibc headers you are using, and the version of the linux-libc-dev (they are intricately intertwined).

[tickets:#2] Please identify versions of gcc etc. you are working with

Status: open
Milestone: 1.0
Created: Sun Oct 06, 2019 01:54 AM UTC by Ed Reed
Last Updated: Sun Oct 06, 2019 01:54 AM UTC
Owner: nobody

Hi - glad to see you doing this work.

Could you give us what version of gcc you're using? Some things like (as you point out in the source) the call to x86.get_pc_thunk.ax are "very compiler dependent", and that symbol doesn't appear to be in my gcc 4.8.5 version. So, rather than begin a binary search of versions, I thought I'd ask.

And while you're at it, if you identified the kernel version you're working with, it would help nail down things like VFS_CAP_REVISION_3, which my SUSE Leap 42.3 (Linux 4.4.76-1-default) does't know about. I don't object to getting a later version, but would like to know what you're using.

Thanks,
Ed

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ibcs-us/tickets/2/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Ed Reed]

For the record, rediscovering this response, rather than asking it again ;-)

Debian files, here I come.