On 10-04-2009, Florian Weimer <f...@deneb.enyo.de> wrote: > * Sylvain Le Gall: > >>> byterun/ints.c, function caml_int64_div, the I64_div macro. This is >>> expanded into a plain division operator, and that is compiled into a >>> run-time library call by GCC. >>> >> >> I64_div is a function defined either in byterun/int64_emul.h o >> byterun/int64_native.h. Reading both I64_div, I don't see any specific >> GCC usage. >> >> Could you be more precise ? I must admit I don't understand at all this >> issue ! > > Here's a disassembly of the caml_int64_div function in ocaml 3.10.2 > > 00000e19 <caml_int64_div>: > e19: 55 push %ebp > e1a: 89 e5 mov %esp,%ebp > e1c: 83 ec 18 sub $0x18,%esp > e1f: 8b 45 0c mov 0xc(%ebp),%eax > e22: 8b 50 08 mov 0x8(%eax),%edx > e25: 8b 40 04 mov 0x4(%eax),%eax > e28: 89 d1 mov %edx,%ecx > e2a: 09 c1 or %eax,%ecx > e2c: 75 05 jne e33 <caml_int64_div+0x1a> > e2e: e8 fc ff ff ff call e2f <caml_int64_div+0x16> > e2f: R_386_PC32 caml_raise_zero_divide > e33: 89 44 24 08 mov %eax,0x8(%esp) > e37: 89 54 24 0c mov %edx,0xc(%esp) > e3b: 8b 4d 08 mov 0x8(%ebp),%ecx > e3e: 8b 41 04 mov 0x4(%ecx),%eax > e41: 8b 51 08 mov 0x8(%ecx),%edx > e44: 89 04 24 mov %eax,(%esp) > e47: 89 54 24 04 mov %edx,0x4(%esp) > e4b: e8 fc ff ff ff call e4c <caml_int64_div+0x33> > e4c: R_386_PC32 __divdi3 > e50: 89 04 24 mov %eax,(%esp) > e53: 89 54 24 04 mov %edx,0x4(%esp) > e57: e8 fc ff ff ff call e58 <caml_int64_div+0x3f> > e58: R_386_PC32 caml_copy_int64 > e5c: c9 leave > e5d: c3 ret > > The actual division is carried out by calling __divdi3. This function > is implemented in the GCC run-time library, and statically linked into > the executable. > > Note that this is just an example. Other, similar issues probably > exist on other architectures (particular RISCy ones). > >
Just for the sake of my own comprehesion (and future reader of this thread), let me rephrase the problem : - GCC 4.4 add dependency to a GPLv3 library - Some part of ocamlopt get GCC 4.4 new dependency - ocamlopt is licensed under QPL - GCC GPLv3 library has an exception that allow non-compiler usage - ocamlopt end up with GPLv3 and QPL which is a problem OK, so GCC embed its own code in the produced code making non-GPLv3 compiler outlaw. This is VERY unfortunate and should lead to a lot more problem than just with OCaml. I don't think there is anything the OCaml Debian Packaging can do about this issue (nor the OCaml upstream author). Maybe you can create a bug against GCC to at least provide an alternative to this situation (going back to GCC 4.3 behavior when --no-link-GPLv3 is set at gcc invocation). I agree with you that GCC 4.4 should not become default compiler for Sid/Squeeze with this kind of bug. Now, what can save OCaml, IMHO. The dependency added to ocamlopt is related to a runtime library and not at all to the compilation process. In other word we don't combine "the Runtime Library with Independent Modules". And ocamlopt emit assembler instruction that is passed to gas for compilation into target code. So to my mind, OCaml can be seen as source code generators for gas... (ok producing gas source code is quite near to producing target code but it is not yet possible to use it on the machine). Would this way of thinking stand regarding the runtime exception ? Regards, Sylvain Le Gall Regards, Sylvain Le Gall -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
