Regarding

- have you tried to disassemble both (static,dynamic) versions and to compare them ?

...

Does optimization level affect the behavior ? I.e. what about -O0, for example ?

So for you the fact I've never asked a question on a forum makes you understand that I don't know how to trace and pinpoint a bug ?

I said I use Slackware64 (forgot to mention -current, true), "raw" I don't have anything special, I was wondering if other had this bug on their installs.

Again : forum newbie != programming newbie.

FYI : my 'experience' is not my number of posts here, it's the fact that I first used slackware early 90s, I've been programming for more than 20 years, using several languages, on several system, several compilers, and I don't feel the need to post my curriculum vitae if I find a bug in some piece of code. And if I don't post 'often' (3 times in my whole 20years internet/programmer lifespan), it's might be because :
* I google before posting
* I want to avoid "unrelated/pedantic/have you seen that I know better than you on this irrelevant detail?" answers as they are so many around
* I'm used to find a solution myself (with help of docs of course) most of the time.
* ..several minor issues...

For the rest it is still unrelated to a mismatch of pointer size on the return instruction of an empty system callback.

For "the other post", as I think it's a Slackware64 specific build problem I 'asked' the slackware dudes "around". Is there something wrong to try to address the right person who will be able to answer to your problem ?

Cheers.

Errr... I use a debugger...You know that kind of thing that allows you to trace the assembly, see the registers, watch memory... (gdb through ddd in that case)...

So Yes... I watched everything, I have several compilation settings, and nothing 'magic' with an empty function again, and a simple retq into the kernel...

Sure I know. More than twenty years ago my friend and I developed an in-circuit emulator, and I personally wrote for it a debugger.

Also, during VLSI stage of my career, I was developing simulation environments for chips containing CPUs, so had to convert input sources into readable by Verilog hex files. Quite "fun" to find and fix one's errors having simulation speed of one CPU clock per second.

Regarding "I watched everything" - I can tell you what I once read in a novel, which said it was written in a NYC elevator: "If you are so smart, why are you so poor ?".

If you want something constructive, stop bragging and publish disassembly of the static and dynamic versions.

Yeah, I didn't want to compete or start any mind war here.

I was just saying, that the 'hint' was pointless regarding the problem, and I might have over-reacted because it's been several weeks I was trying to understand a bug on my side where it seems it's a distribution build problem (it's been confirmed on the "slackware forum thread"). You didn't have all the infos, I know that, I was just tired of having to explain "from the start" where I was on the stage of asking "why kernel calls me in 32bit whereas I'm a 64bit process"...
(Yes "weeks" might be long but it's on my spare time...And I didn't want to bother anyone while I wasn't 100% sure it was not my fault)

Anyway, I appreciate you've spent time on this. I'm continuing digging this problem on the slackware specific forum...

But... If any of you have an idea how to understand/debug this problem, even if you're not a slacky, you're welcomed :).

It implies 64bit static linking and kernel/system call mismatch (possibly glibc)...

Cheers

Garry.

A person with 20 years of experience should have a strong idea that compiler + linker + glibc strongly affect the final code produced.

A person who read the thread carefully could notice that ntubski has checked your code and it worked for him. So, it would be logical to ask ntubski to send the binary he used and try it - since the linking is static, the binary should work more or less out of the box.

If by any chance ntubski's binary works under your system, the problem is most likely in the compiler + linker + glibc combination.

Or you could not ask anybody anything, install (probably in a VM) the same Ubuntu version ntubski used and try it yourself.