This simplify the code, would have prevented GPR#205 and prepare ground
for upcoming improved backtrace generation.
From: Frédéric Bour <frederic.bour@lakaban.net>
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16367 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
And share backtrace.c between asmrun and byterun.
From: Frédéric Bour <frederic.bour@lakaban.net>
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16365 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Pierre Chambart)
When allocating this kind of blocks to the minor heap, they are
added to 'caml_finalize_table' which is traversed on
'caml_empty_table' to check if any of such block is dead.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16357 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
There is currently a GC bug in the bytecode debug-info handling, due
to the fact that
void read_main_debug_info(struct debug_info *di)
is passed a internal pointer in the middle of a custom block inside
the OCaml heap. I could only observe the bug when such custom blocks
are allocated on the minor heap -- which does not happen with the
current implementation, but becomes possible after GPR#92 for example
(which let custom blocks with finalizer be allocated in the
minor heap).
This commit fixes this issue by moving debug_info chunks from the
OCaml heap to the C land, stored in a dynamic table. They are
allocated when caml_add_debug_info is called, and removed when
caml_remove_debug_info is called.
(Another approach would be to keep the debug_info inside the OCaml
heap, but make sure that there are no dangling internal pointers. See
GPR#228 for an attack of this by Mark Shinwell.)
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16356 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This is a follow-up to commit r16245, PR#6902, GPR#210.
- Runtime warning machinery was local to io.c; make it globally usable.
- Move definitions and accessor functions to misc.c and gc_ctrl.c
by analogy with other configurable runtime parameters.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16325 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
- Primitives:
caml_float_of_string extended to recognize "0x" hexa notation
caml_hexstring_of_float new primitive
We do not assume hex floats are supported by the C standard library.
Instead, conversions hex string <-> float are implemented manually.
- Printf: hex FP output supported with formats %h / %H
- Scanf: remains to be updated (see TODO in stdlib/scanf.ml)
git-svn-id: http://caml.inria.fr/svn/ocaml/branches/hex-float@16257 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Thomas Refis)
The constants weren't just renammed: they previously denoted a size in bytes,
they now denote a size in words.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16251 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
configure: deselect ocamlopt, which is not supported
signals_machdep.h: use i386 instruction sequence, not amd64.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16243 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The approach implemented is the second one suggested by Benoît Vaugon in the PR:
- The int_of_string functions accept a "0u" prefix meaning "decimal unsigned".
- The '%u' format of the scanf functions adds this "0u" prefix before conversion.
This is consistent with the current handling of unsigned hexa, octal, and binary numbers.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16241 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Peter Zotov, review by Mark Shinwell)
NB: after applying this change you need to run ./configure again.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16068 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Peter Zotov and Jake Donham,
review by Gabriel Scherer and Jacques-Henri Jourdan)
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15830 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
- document most of the "size" and "length" parameters and global variables,
specifying bytes or words. Change some of them from bytes to words.
- start getting rid of "char *" and use sensible types instead.
- other small changes
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15647 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
It allows to have non-standard limits for non-standard runtime.
ie: js_of_ocaml use 32bits integer, and can handle
string much bigger than 16Mo.
From: Hugo Heuzard <hugo.heuzard@gmail.com>
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15588 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Jacques-Henri initially removed the primitive, which is deprecated
since 4.01, but I suspect there still are uses in the wild. I guess we
should wait for a few more versions.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14780 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(Patch by Jacques-Henri Jourdan)
There are several changes:
- `raw_backtrace` is no longer an abstract type, but rather an
`raw_backtrace_slot array`, where `raw_backtrace_slot` is a new
abstract type. `raw_backtrace_slot` elements are hashable and
comparable. At runtime, values of this type contain either
a bytecode pointer or a frame_descr pointer. In order to prevent the
GC from walking through this pointer, the low-order bit is set to
1 when stored in the array.
- The old `loc_info` type is know public, renamed into `backtrace_slot`:
type backtrace_slot =
| Known_location of bool (* is_raise *)
* string (* filename *)
* int (* line number *)
* int (* start char *)
* int (* end char *)
| Unknown_location of bool (*is_raise*)
- new primitive :
val convert_raw_backtrace_slot: raw_backtrace_slot -> backtrace_slot
Rather than returning an option, it raises Failure when it is not
possible to get the debugging information. It seems more idiomatic,
especially because the exceptional case cannot appear only for a part
of the executable.
- the caml_convert_raw_backtrace primitive is removed; it is more
difficult to implement in the C side because of the new exception
interface described above.
- In the bytecode runtime, the events are no longer deserialized once
for each conversion, but once and for all at the first conversion,
and stored in a global array (*outside* the OCaml heap), sorted by
program counter value. I believe this information should not take
much memory in practice (it uses the same order of magnitude memory
as the bytecode executable). It also makes location lookup much more
efficient, as a dichomoty is used instead of linear search as
previously.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14776 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
- configure: no change necessary
- byterun/config.h: make sure ARCH_INT64_TYPE and related macros
are always defined, for Coq and others to use.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14636 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
and maybe others rely on it
byterun/config.h: select "long long" in preference to "long" for "int64",
just because this is how it was done in earlier versions.
(Minimizing suprises.)
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14635 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
An ISO C99-compliant C compiler and standard library is now assumed.
(Plus special exceptions for MSVC.) In particular, emulation code for
64-bit integer arithmetic was removed, the C compiler must support a
64-bit integer type.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14607 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(patch by Josh Watzman)
Add absolute directory names to bytecode format for ocamldebug to use
The need for a long list of -I directives makes interactively using
ocamldebug a pain in the butt. Many folks have solved this with various
`find` invocations or even Python wrappers, but those lead to other
problems when it might include files you weren't expecting (or miss
things you were). But all of this is really annoying since the tooling
should be able to figure out itself, even heuristically, where your
source files are -- gdb gets this right, why can't we?
This patch implements one of the more important heuristics from gdb: you
typically debug on the same machine you built on, so looking for the
source files and built artifacts in the absolute paths where they were
during compilation is a good first try. We write out absolute paths into
a new structure at the beginning of the debug section and then
automatically append those directories into the load path.
This means mean that if you happen to be debugging on a machine
where the original source and build artifacts are *not* available in
their original absolute locations, things will work as before, using the
standard load path mechanism. You can also explicitly use -I to prepend
directories to the load path and override the defaults located by this
new mechanism.
I personally find this makes using ocamldebug much more pleasant :)
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14533 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
There seems to be a problematic interaction with backtrace collection. To test this,
make world.opt
cd testsuite
make one DIR=tests/backtrace/
This needs to be sorted out before the patch can go in again.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14510 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Noticed that I had to bootstrap to test on ARM, so I commit a new bootstrap
compiler.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14479 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
As notified by Nicolas Trangez, the following program behaves in an
unexpected way by returning 0 instead of failing with an out-of-bound
exception:
external get16 : string -> int -> int = "%caml_string_get16"
let test = get16 "" 0
caml_string_get16(str, idx) will access indices (idx) and (idx+1). The
bound-checking code is currently implemented as:
if (idx < 0 || idx >= caml_string_length(str) - 1) caml_array_bound_error();
This is wrong as caml_string_length returns an mlsize_t which is
unsigned, so substracting 1 gets buggy when the size is 0. The test
should be written as follow:
if (idx < 0 || idx + 1 >= caml_string_length(str)) caml_array_bound_error();
Note 1: we can exploit this bug to make out-of-bound access to
a string, but I think get16 examples will run into the padding
characters of OCaml strings and behave in a not-too-wrong way. It may
also be the case of get32, but get64 will access 7 bytes, so access
memory outside the string:
# external set64: string -> int -> int -> unit = "%caml_string_get64";;
external set64 : string -> int -> int -> unit = "%caml_string_get64"
# set64 "" 0 0;;
Segmentation fault
Note 2: this first commit only fixes the C code in byterun/str.c. Only
ocamlc actually uses these functions when the compiler primitive is
used ("%caml_string_get16" instead of "caml_string_get16"). ocamlopt
generates ocaml code directly, and this part has yet to be fixed in
a following commit.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14267 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
of size 2, with tag = Object_tag, the first field being the pointer to the string, and second one being a unique id, generated
from the same sequence as for object values. Special case for predefined exceptions, represented with a negative id.
The unique id generator is moved from camlinternalOO to the C runtime system.
Also fix some bugs.
git-svn-id: http://caml.inria.fr/svn/ocaml/branches/raise_variants@14239 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The OpenBSD Jenkins slave started failing because of the use of
gnu-style conditionals.
There's unfortunately no way that I know of to get a conditional syntax
that works both with gmake and mk.
Fortunately, the conditional wasn't needed at all since the value was
already computed in the configure step.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13861 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
This commit only implements runtime support in asmrun/ and byterun/.
The more subjective Printexc interface will come separately.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13813 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02