[Qemu-devel] [RFC PATCH] tcg: add ability to dump /tmp/perf-pid.map files

2014-03-27 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

This allows the perf tool to map samples to each individual translation
block. This could be expanded for user space but currently it gives
enough information to find any hotblocks by other means.
---
 qemu-options.hx | 10 ++
 tcg/tcg.c   | 21 +
 vl.c|  6 ++
 3 files changed, 37 insertions(+)

diff --git a/qemu-options.hx b/qemu-options.hx
index c5577be..09fb1d0 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2683,6 +2683,16 @@ Will dump output for any code in the 0x1000 sized block 
starting at 0x8000 and
 the 0x200 sized block starting at 0xffc8.
 ETEXI
 
+DEF(perfmap, 0, QEMU_OPTION_PERFMAP, \
+-perfmap  generate a /tmp/perf-${pid}.map file for perf\n,
+QEMU_ARCH_ALL)
+STEXI
+@item -perfmap
+@findex -perfmap
+This will cause QEMU to generate a map file for Linux perf tools that will 
allow
+basic profiling information to be broken down into basic blocks.
+ETEXI
+
 DEF(L, HAS_ARG, QEMU_OPTION_L, \
 -L path set the directory for the BIOS, VGA BIOS and keymaps\n,
 QEMU_ARCH_ALL)
diff --git a/tcg/tcg.c b/tcg/tcg.c
index 57d2b82..a24f581 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -27,6 +27,8 @@
 #define USE_TCG_OPTIMIZATIONS
 
 #include config.h
+#include glib.h
+#include glib/gstdio.h
 
 /* Define to jump the ELF file used to communicate with GDB.  */
 #undef DEBUG_JIT
@@ -106,6 +108,8 @@ static int tcg_target_const_match(tcg_target_long val,
 static void tcg_out_tb_init(TCGContext *s);
 static void tcg_out_tb_finalize(TCGContext *s);
 
+static void tcg_write_perfmap(uint8_t *start, uint64_t size, uint64_t 
target_pc);
+void qemu_tcg_enable_perfmap(void);
 
 TCGOpDef tcg_op_defs[] = {
 #define DEF(s, oargs, iargs, cargs, flags) { #s, oargs, iargs, cargs, iargs + 
oargs + cargs, flags },
@@ -2575,6 +2579,8 @@ static inline int tcg_gen_code_common(TCGContext *s, 
uint64_t target_pc,
  the_end:
 /* Generate TB finalization at the end of block */
 tcg_out_tb_finalize(s);
+
+tcg_write_perfmap(gen_code_buf, s-code_ptr - gen_code_buf, target_pc);
 return -1;
 }
 
@@ -2666,6 +2672,21 @@ void tcg_dump_info(FILE *f, fprintf_function cpu_fprintf)
 }
 #endif
 
+static FILE *tcg_perfmap = NULL;
+void qemu_tcg_enable_perfmap(void) {
+gchar * map_file = g_strdup_printf(/tmp/perf-%d.map, getpid());
+tcg_perfmap = g_fopen(map_file, w);
+g_free(map_file);
+}
+
+static void tcg_write_perfmap(uint8_t *start, uint64_t size, uint64_t 
target_pc)
+{
+if (tcg_perfmap) {
+g_fprintf(tcg_perfmap, %lx %lx subject-0x%lx\n,
+  (uint64_t) start, size, target_pc);
+}
+}
+
 #ifdef ELF_HOST_MACHINE
 /* In order to use this feature, the backend needs to do three things:
 
diff --git a/vl.c b/vl.c
index c036367..f1c3c3d 100644
--- a/vl.c
+++ b/vl.c
@@ -123,6 +123,9 @@ int main(int argc, char **argv)
 #define MAX_VIRTIO_CONSOLES 1
 #define MAX_SCLP_CONSOLES 1
 
+/* seems better than pulling in all the tcg headers? */
+extern void qemu_tcg_enable_perfmap(void);
+
 static const char *data_dir[16];
 static int data_dir_idx;
 const char *bios_name = NULL;
@@ -3345,6 +3348,9 @@ int main(int argc, char **argv, char **envp)
 case QEMU_OPTION_DFILTER:
 qemu_set_dfilter_ranges(optarg);
 break;
+case QEMU_OPTION_PERFMAP:
+qemu_tcg_enable_perfmap();
+break;
 case QEMU_OPTION_s:
 add_device_config(DEV_GDB, tcp:: DEFAULT_GDBSTUB_PORT);
 break;
-- 
1.9.1

[Qemu-devel] [RFC PATCH 0/4] qemu-log: various fixes and enhancements

2014-03-26 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

Hi,

While working on aarch64 stuff I've made the following changes in my
local tree to help me debug. The first is a simple documentation fix.
The second is very helpful when your debugging missing instructions
while several shells deep in a build system. The final two I've
recently written as I'm doing some system mode debugging and found
that it's hard to have all the code gen logs turned on when your test
case is booting the kernel.

Comments and review please.

Alex Bennée (4):
  qemu-log: correct help text for -d cpu
  qemu-log: support simple pid substitution in logfile
  qemu-log: new option -dfilter to limit output
  qemu-log: make in_asm, out_asm and op_opt understand dfilter

 cpu-exec.c |  2 +-
 include/qemu/log.h |  2 ++
 qemu-log.c | 75 +++---
 qemu-options.hx|  9 +++
 tcg/tcg.c  | 24 -
 tcg/tcg.h  |  5 ++--
 translate-all.c|  7 ++---
 vl.c   |  3 +++
 8 files changed, 105 insertions(+), 22 deletions(-)

-- 
1.9.1

[Qemu-devel] [RFC PATCH 4/4] qemu-log: make in_asm, out_asm and op_opt understand dfilter

2014-03-26 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

This ensures the code generation debug code will honour -dfilter if set.

diff --git a/cpu-exec.c b/cpu-exec.c
index 0914d3c..9aa3f3f 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -610,7 +610,7 @@ int cpu_exec(CPUArchState *env)
 next_tb = 0;
 tcg_ctx.tb_ctx.tb_invalidated_flag = 0;
 }
-if (qemu_loglevel_mask(CPU_LOG_EXEC)) {
+if (qemu_loglevel_mask(CPU_LOG_EXEC)  
qemu_log_in_addr_range(tb-pc)) {
 qemu_log(Trace %p [ TARGET_FMT_lx ] %s\n,
  tb-tc_ptr, tb-pc, lookup_symbol(tb-pc));
 }
diff --git a/tcg/tcg.c b/tcg/tcg.c
index f1e0763..57d2b82 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -2452,8 +2452,8 @@ static void dump_op_count(void)
 #endif
 
 
-static inline int tcg_gen_code_common(TCGContext *s, uint8_t *gen_code_buf,
-  long search_pc)
+static inline int tcg_gen_code_common(TCGContext *s, uint64_t target_pc,
+  uint8_t *gen_code_buf, long search_pc)
 {
 TCGOpcode opc;
 int op_index;
@@ -2461,7 +2461,8 @@ static inline int tcg_gen_code_common(TCGContext *s, 
uint8_t *gen_code_buf,
 const TCGArg *args;
 
 #ifdef DEBUG_DISAS
-if (unlikely(qemu_loglevel_mask(CPU_LOG_TB_OP))) {
+if (unlikely(qemu_loglevel_mask(CPU_LOG_TB_OP)
+  qemu_log_in_addr_range(target_pc))) {
 qemu_log(OP:\n);
 tcg_dump_ops(s);
 qemu_log(\n);
@@ -2489,7 +2490,8 @@ static inline int tcg_gen_code_common(TCGContext *s, 
uint8_t *gen_code_buf,
 #endif
 
 #ifdef DEBUG_DISAS
-if (unlikely(qemu_loglevel_mask(CPU_LOG_TB_OP_OPT))) {
+if (unlikely(qemu_loglevel_mask(CPU_LOG_TB_OP_OPT)
+  qemu_log_in_addr_range(target_pc))) {
 qemu_log(OP after optimization and liveness analysis:\n);
 tcg_dump_ops(s);
 qemu_log(\n);
@@ -2512,11 +2514,6 @@ static inline int tcg_gen_code_common(TCGContext *s, 
uint8_t *gen_code_buf,
 tcg_table_op_count[opc]++;
 #endif
 def = tcg_op_defs[opc];
-#if 0
-printf(%s: %d %d %d\n, def-name,
-   def-nb_oargs, def-nb_iargs, def-nb_cargs);
-//dump_regs(s);
-#endif
 switch(opc) {
 case INDEX_op_mov_i32:
 case INDEX_op_mov_i64:
@@ -2581,7 +2578,7 @@ static inline int tcg_gen_code_common(TCGContext *s, 
uint8_t *gen_code_buf,
 return -1;
 }
 
-int tcg_gen_code(TCGContext *s, uint8_t *gen_code_buf)
+int tcg_gen_code(TCGContext *s, uint64_t target_pc, uint8_t *gen_code_buf)
 {
 #ifdef CONFIG_PROFILER
 {
@@ -2597,7 +2594,7 @@ int tcg_gen_code(TCGContext *s, uint8_t *gen_code_buf)
 }
 #endif
 
-tcg_gen_code_common(s, gen_code_buf, -1);
+tcg_gen_code_common(s, target_pc, gen_code_buf, -1);
 
 /* flush instruction cache */
 flush_icache_range((uintptr_t)gen_code_buf, (uintptr_t)s-code_ptr);
@@ -2609,9 +2606,10 @@ int tcg_gen_code(TCGContext *s, uint8_t *gen_code_buf)
offset bytes from the start of the TB.  The contents of gen_code_buf must
not be changed, though writing the same values is ok.
Return -1 if not found. */
-int tcg_gen_code_search_pc(TCGContext *s, uint8_t *gen_code_buf, long offset)
+int tcg_gen_code_search_pc(TCGContext *s, uint64_t tpc,
+   uint8_t *gen_code_buf, long offset)
 {
-return tcg_gen_code_common(s, gen_code_buf, offset);
+return tcg_gen_code_common(s, tpc, gen_code_buf, offset);
 }
 
 #ifdef CONFIG_PROFILER
diff --git a/tcg/tcg.h b/tcg/tcg.h
index f7efcb4..9200a25 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -559,8 +559,9 @@ void tcg_context_init(TCGContext *s);
 void tcg_prologue_init(TCGContext *s);
 void tcg_func_start(TCGContext *s);
 
-int tcg_gen_code(TCGContext *s, uint8_t *gen_code_buf);
-int tcg_gen_code_search_pc(TCGContext *s, uint8_t *gen_code_buf, long offset);
+int tcg_gen_code(TCGContext *s, uint64_t tpc, uint8_t *gen_code_buf);
+int tcg_gen_code_search_pc(TCGContext *s, uint64_t tpc,
+   uint8_t *gen_code_buf, long offset);
 
 void tcg_set_frame(TCGContext *s, int reg, intptr_t start, intptr_t size);
 
diff --git a/translate-all.c b/translate-all.c
index f243c10..7596b9c 100644
--- a/translate-all.c
+++ b/translate-all.c
@@ -176,7 +176,7 @@ int cpu_gen_code(CPUArchState *env, TranslationBlock *tb, 
int *gen_code_size_ptr
 s-interm_time += profile_getclock() - ti;
 s-code_time -= profile_getclock();
 #endif
-gen_code_size = tcg_gen_code(s, gen_code_buf);
+gen_code_size = tcg_gen_code(s, tb-pc, gen_code_buf);
 *gen_code_size_ptr = gen_code_size;
 #ifdef CONFIG_PROFILER
 s-code_time += profile_getclock();
@@ -185,7 +185,8 @@ int cpu_gen_code(CPUArchState *env, TranslationBlock *tb, 
int *gen_code_size_ptr
 #endif
 
 #ifdef DEBUG_DISAS
-if (qemu_loglevel_mask(CPU_LOG_TB_OUT_ASM)) {
+if (qemu_loglevel_mask(CPU_LOG_TB_OUT_ASM)
+

[Qemu-devel] [RFC PATCH 2/4] qemu-log: support simple pid substitution in logfile

2014-03-26 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

When debugging stuff that occurs over several forks it would be useful
not to keep overwriting the one logfile you've set-up. This allows a
simple %d to be included once in the logfile parameter which is
substituted with getpid().

Signed-off-by: Alex Bennée alex.ben...@linaro.org

diff --git a/qemu-log.c b/qemu-log.c
index 35bbb56..2897596 100644
--- a/qemu-log.c
+++ b/qemu-log.c
@@ -81,11 +81,24 @@ void do_qemu_set_log(int log_flags, bool use_own_buffers)
 qemu_log_close();
 }
 }
-
+/*
+ * Allow the user to include %d in their logfile which will be
+ * substituted with the current PID. This is useful for debugging many
+ * nested linux-user tasks but will result in lots of logs.
+ */
 void qemu_set_log_filename(const char *filename)
 {
 g_free(logfilename);
-logfilename = g_strdup(filename);
+if (g_strrstr(filename, %d)) {
+/* if we are going to format this we'd better validate first */
+if (g_regex_match_simple(^[^%]+%d[^%]+$, filename, 0, 0)) {
+logfilename = g_strdup_printf(filename, getpid());
+} else {
+g_error(Bad logfile format: %s, filename);
+}
+} else {
+logfilename = g_strdup(filename);
+}
 qemu_log_close();
 qemu_set_log(qemu_loglevel);
 }
-- 
1.9.1

[Qemu-devel] [RFC PATCH 1/4] qemu-log: correct help text for -d cpu

2014-03-26 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

This doesn't just dump CPU state on translation but on every block
entrance.

Signed-off-by: Alex Bennée alex.ben...@linaro.org

diff --git a/qemu-log.c b/qemu-log.c
index 797f2af..35bbb56 100644
--- a/qemu-log.c
+++ b/qemu-log.c
@@ -105,7 +105,7 @@ const QEMULogItem qemu_log_items[] = {
 { CPU_LOG_EXEC, exec,
   show trace before each executed TB (lots of logs) },
 { CPU_LOG_TB_CPU, cpu,
-  show CPU state before block translation },
+  show CPU registers before each executed TB (lots of logs) },
 { CPU_LOG_PCALL, pcall,
   x86 only: show protected mode far calls/returns/exceptions },
 { CPU_LOG_RESET, cpu_reset,
-- 
1.9.1

[Qemu-devel] [RFC PATCH 3/4] qemu-log: new option -dfilter to limit output

2014-03-26 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

When debugging big programs or system emulation sometimes you want both
the verbosity of cpu,exec et all but don't want to generate lots of logs
for unneeded stuff. This patch adds a new option -dfilter which allows
you to specify interesting address ranges in the form:

  -dfilter 0x8000-0x9000,0xffc8+0x200,...

Then logging code can use the new qemu_log_in_addr_range() function to
decide if it will output logging information for the given range.

Signed-off-by: Alex Bennée alex.ben...@linaro.org

diff --git a/include/qemu/log.h b/include/qemu/log.h
index d515424..25710ad 100644
--- a/include/qemu/log.h
+++ b/include/qemu/log.h
@@ -174,6 +174,8 @@ static inline void qemu_set_log(int log_flags)
 }
 
 void qemu_set_log_filename(const char *filename);
+void qemu_set_dfilter_ranges(const char *ranges);
+bool qemu_log_in_addr_range(uint64_t addr);
 int qemu_str_to_log_mask(const char *str);
 
 /* Print a usage message listing all the valid logging categories
diff --git a/qemu-log.c b/qemu-log.c
index 2897596..e2fa3fd 100644
--- a/qemu-log.c
+++ b/qemu-log.c
@@ -19,11 +19,13 @@
 
 #include qemu-common.h
 #include qemu/log.h
+#include qemu/range.h
 
 static char *logfilename;
 FILE *qemu_logfile;
 int qemu_loglevel;
 static int log_append = 0;
+static GSList *debug_regions = NULL;
 
 void qemu_log(const char *fmt, ...)
 {
@@ -103,6 +105,60 @@ void qemu_set_log_filename(const char *filename)
 qemu_set_log(qemu_loglevel);
 }
 
+/* Returns true if addr is in our debug filter or no filter defined
+ */
+bool qemu_log_in_addr_range(uint64_t addr)
+{
+if (debug_regions) {
+GSList *region = debug_regions;
+do {
+struct Range *range = region-data;
+if (addr = range-begin  addr = range-end) {
+return true;
+}
+region = g_slist_next(region);
+} while (region);
+return false;
+} else {
+return true;
+}
+}
+
+
+void qemu_set_dfilter_ranges(const char *filter_spec)
+{
+gchar **ranges = g_strsplit(filter_spec, ,, 0);
+if (ranges) {
+gchar **next = ranges;
+gchar *r = *next++;
+while (r) {
+gchar *delim = g_strrstr(r, -);
+if (!delim) {
+delim = g_strrstr(r, +);
+}
+if (delim) {
+struct Range *range = g_malloc(sizeof(Range));
+range-begin = strtoul(r, NULL, 0);
+switch (*delim) {
+case '+':
+range-end = range-begin + strtoul(delim+1, NULL, 0);
+break;
+case '-':
+range-end = strtoul(delim+1, NULL, 0);
+break;
+default:
+g_assert_not_reached();
+}
+debug_regions = g_slist_append(debug_regions, range);
+} else {
+g_error(Bad range specifier in: %s, r);
+}
+r = *next++;
+}
+g_strfreev(ranges);
+}
+}
+
 const QEMULogItem qemu_log_items[] = {
 { CPU_LOG_TB_OUT_ASM, out_asm,
   show generated host assembly code for each compiled TB },
diff --git a/qemu-options.hx b/qemu-options.hx
index ee5437b..a5cd095 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2667,6 +2667,15 @@ STEXI
 Output log in @var{logfile} instead of to stderr
 ETEXI
 
+DEF(dfilter, HAS_ARG, QEMU_OPTION_DFILTER, \
+-dfilter range,..  filter debug output to range of addresses (useful for 
-d cpu,exec,etc..)\n,
+QEMU_ARCH_ALL)
+STEXI
+@item -dfilter @var{range1}[,...]
+@findex -dfilter
+Filter debug output to that relevant to a range of target addresses
+ETEXI
+
 DEF(L, HAS_ARG, QEMU_OPTION_L, \
 -L path set the directory for the BIOS, VGA BIOS and keymaps\n,
 QEMU_ARCH_ALL)
diff --git a/vl.c b/vl.c
index 02bf8ec..c036367 100644
--- a/vl.c
+++ b/vl.c
@@ -3342,6 +3342,9 @@ int main(int argc, char **argv, char **envp)
 case QEMU_OPTION_D:
 log_file = optarg;
 break;
+case QEMU_OPTION_DFILTER:
+qemu_set_dfilter_ranges(optarg);
+break;
 case QEMU_OPTION_s:
 add_device_config(DEV_GDB, tcp:: DEFAULT_GDBSTUB_PORT);
 break;
-- 
1.9.1

[Qemu-devel] [PATCH] trace: teach lttng backend to use format strings

2014-03-24 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

This makes the UST backend pay attention to the format string arguments
that are defined when defining payload data. With this you can now
ensure integers are reported in hex mode if you want.

Signed-off-by: Alex Bennée alex.ben...@linaro.org
---
 scripts/tracetool/__init__.py| 13 +++--
 scripts/tracetool/backend/ust.py | 16 
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index 175df08..abcdc49 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -118,13 +118,16 @@ class Event(object):
 Properties of the event.
 args : Arguments
 The event arguments.
+arg_fmts : str
+The format strings for each arugment.
 
 
 _CRE = 
re.compile(((?Pprops.*)\s+)?(?Pname[^(\s]+)\((?Pargs[^)]*)\)\s*(?Pfmt\.*)?)
+_FMT = re.compile((%\w+|%.*PRI\S+))
 
 _VALID_PROPS = set([disable])
 
-def __init__(self, name, props, fmt, args):
+def __init__(self, name, props, fmt, args, arg_fmts):
 
 Parameters
 --
@@ -136,11 +139,15 @@ class Event(object):
 Event printing format.
 args : Arguments
 Event arguments.
+arg_fmts : list of str
+Format strings for each argument
+
 
 self.name = name
 self.properties = props
 self.fmt = fmt
 self.args = args
+self.arg_fmts = arg_fmts
 
 unknown_props = set(self.properties) - self._VALID_PROPS
 if len(unknown_props)  0:
@@ -163,8 +170,10 @@ class Event(object):
 props = groups[props].split()
 fmt = groups[fmt]
 args = Arguments.build(groups[args])
+print %s: %s and %s % (name, args, fmt)
+arg_fmts = Event._FMT.findall(fmt)
 
-return Event(name, props, fmt, args)
+return Event(name, props, fmt, args, arg_fmts)
 
 def __repr__(self):
 Evaluable string representation for this object.
diff --git a/scripts/tracetool/backend/ust.py b/scripts/tracetool/backend/ust.py
index 41c1c75..cb09958 100644
--- a/scripts/tracetool/backend/ust.py
+++ b/scripts/tracetool/backend/ust.py
@@ -56,13 +56,21 @@ def ust_events_h(events):
 args = , .join(, .join(i) for i in e.args),
 )
 
-for t,n in e.args:
-if ('int' in t) or ('long' in t) or ('unsigned' in t) or 
('size_t' in t):
+types = e.args.types()
+names = e.args.names()
+fmts = e.arg_fmts
+print /* %s/%s/%s */ % (types, names, fmts)
+for t,n,f in zip(types, names, fmts):
+if ('char *' in t) or ('char*' in t):
+out('   ctf_string(' + n + ', ' + n + ')')
+elif (%p in f) or (x in f) or (PRIx in f):
+out('   ctf_integer_hex('+ t + ', ' + n + ', ' + n + 
')')
+elif (ptr in t) or (* in t):
+out('   ctf_integer_hex('+ t + ', ' + n + ', ' + n + 
')')
+elif ('int' in t) or ('long' in t) or ('unsigned' in t) or 
('size_t' in t):
 out('   ctf_integer(' + t + ', ' + n + ', ' + n + ')')
 elif ('double' in t) or ('float' in t):
 out('   ctf_float(' + t + ', ' + n + ', ' + n + ')')
-elif ('char *' in t) or ('char*' in t):
-out('   ctf_string(' + n + ', ' + n + ')')
 elif ('void *' in t) or ('void*' in t):
 out('   ctf_integer_hex(unsigned long, ' + n + ', ' + 
n + ')')
 
-- 
1.9.1

[Qemu-devel] [PATCH] trace: teach lttng backend to use format strings

2014-03-24 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

This makes the UST backend pay attention to the format string arguments
that are defined when defining payload data. With this you can now
ensure integers are reported in hex mode if you want.

Signed-off-by: Alex Bennée alex.ben...@linaro.org

---

v2
  - remove silly debug statements
---
 scripts/tracetool/__init__.py| 12 ++--
 scripts/tracetool/backend/ust.py | 17 -
 2 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index 175df08..71e2ab5 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -118,13 +118,16 @@ class Event(object):
 Properties of the event.
 args : Arguments
 The event arguments.
+arg_fmts : str
+The format strings for each arugment.
 
 
 _CRE = 
re.compile(((?Pprops.*)\s+)?(?Pname[^(\s]+)\((?Pargs[^)]*)\)\s*(?Pfmt\.*)?)
+_FMT = re.compile((%\w+|%.*PRI\S+))
 
 _VALID_PROPS = set([disable])
 
-def __init__(self, name, props, fmt, args):
+def __init__(self, name, props, fmt, args, arg_fmts):
 
 Parameters
 --
@@ -136,11 +139,15 @@ class Event(object):
 Event printing format.
 args : Arguments
 Event arguments.
+arg_fmts : list of str
+Format strings for each argument
+
 
 self.name = name
 self.properties = props
 self.fmt = fmt
 self.args = args
+self.arg_fmts = arg_fmts
 
 unknown_props = set(self.properties) - self._VALID_PROPS
 if len(unknown_props)  0:
@@ -163,8 +170,9 @@ class Event(object):
 props = groups[props].split()
 fmt = groups[fmt]
 args = Arguments.build(groups[args])
+arg_fmts = Event._FMT.findall(fmt)
 
-return Event(name, props, fmt, args)
+return Event(name, props, fmt, args, arg_fmts)
 
 def __repr__(self):
 Evaluable string representation for this object.
diff --git a/scripts/tracetool/backend/ust.py b/scripts/tracetool/backend/ust.py
index 41c1c75..6223f20 100644
--- a/scripts/tracetool/backend/ust.py
+++ b/scripts/tracetool/backend/ust.py
@@ -56,13 +56,20 @@ def ust_events_h(events):
 args = , .join(, .join(i) for i in e.args),
 )
 
-for t,n in e.args:
-if ('int' in t) or ('long' in t) or ('unsigned' in t) or 
('size_t' in t):
+types = e.args.types()
+names = e.args.names()
+fmts = e.arg_fmts
+for t,n,f in zip(types, names, fmts):
+if ('char *' in t) or ('char*' in t):
+out('   ctf_string(' + n + ', ' + n + ')')
+elif (%p in f) or (x in f) or (PRIx in f):
+out('   ctf_integer_hex('+ t + ', ' + n + ', ' + n + 
')')
+elif (ptr in t) or (* in t):
+out('   ctf_integer_hex('+ t + ', ' + n + ', ' + n + 
')')
+elif ('int' in t) or ('long' in t) or ('unsigned' in t) or 
('size_t' in t):
 out('   ctf_integer(' + t + ', ' + n + ', ' + n + ')')
 elif ('double' in t) or ('float' in t):
 out('   ctf_float(' + t + ', ' + n + ', ' + n + ')')
-elif ('char *' in t) or ('char*' in t):
-out('   ctf_string(' + n + ', ' + n + ')')
 elif ('void *' in t) or ('void*' in t):
 out('   ctf_integer_hex(unsigned long, ' + n + ', ' + 
n + ')')
 
@@ -79,4 +86,4 @@ def ust_events_h(events):
 ')',
 '',
 name = e.name,
-)
\ No newline at end of file
+)
-- 
1.9.1

[Qemu-devel] [RCF PATCH 0/2] Improving TCG debug output

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

Hi,

These two patches have been sitting in my personal tree for a while
and I thought it was worth soliciting feedback as to their wider usefulness.

The first is simply an attempt to make tcg abort failures a little
less terse.

The second I found useful when I was debugging a complex set of TCG
ops for a round, shift and narrow implementation. The alternative was
to set up GDB and step through the generated target code (or just
infer from the copious dumps). The macro magic might be a bit much though.

Alex Bennée (2):
  tcg: add tcg_abort_dbg() for additional debug info
  tcg: add debug helpers tcg_debug_dump_i(32|64)

 Makefile.target   |  2 +-
 target-arm/helper.h   |  2 ++
 tcg/i386/tcg-target.c |  4 ++--
 tcg/optimize.c|  2 +-
 tcg/tcg-helpers.c | 32 +
 tcg/tcg-helpers.h | 57 +++
 tcg/tcg.h |  7 +--
 7 files changed, 100 insertions(+), 6 deletions(-)
 create mode 100644 tcg/tcg-helpers.c
 create mode 100644 tcg/tcg-helpers.h

-- 
1.9.0

[Qemu-devel] [RCF PATCH 2/2] tcg: add debug helpers tcg_debug_dump_i(32|64)

2014-03-12 Thread alex . bennee 
From: Alex Benn??e alex.ben...@linaro.org

The helpers are useful for debugging if you want to inspect interim
values of tcg temp variables while executing TCG generated code. This is
an alternative to tracing with logs or inspecting with GDB.

The functions do take format strings but to prevent massive memory loss
it will default to a constant string after a short number of uses.

 create mode 100644 tcg/tcg-helpers.c
 create mode 100644 tcg/tcg-helpers.h

diff --git a/Makefile.target b/Makefile.target
index ba12340..a87b7d7 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -73,7 +73,7 @@ all: $(PROGS) stap
 #
 # cpu emulator library
 obj-y = exec.o translate-all.o cpu-exec.o
-obj-y += tcg/tcg.o tcg/optimize.o
+obj-y += tcg/tcg.o tcg/optimize.o tcg/tcg-helpers.o
 obj-$(CONFIG_TCG_INTERPRETER) += tci.o
 obj-$(CONFIG_TCG_INTERPRETER) += disas/tci.o
 obj-y += fpu/softfloat.o
diff --git a/target-arm/helper.h b/target-arm/helper.h
index 8923f8a..7600c21 100644
--- a/target-arm/helper.h
+++ b/target-arm/helper.h
@@ -507,4 +507,6 @@ DEF_HELPER_FLAGS_3(crc32c, TCG_CALL_NO_RWG_SE, i32, i32, 
i32, i32)
 #include helper-a64.h
 #endif
 
+#include tcg/tcg-helpers.h
+
 #include exec/def-helper.h
diff --git a/tcg/tcg-helpers.c b/tcg/tcg-helpers.c
new file mode 100644
index 000..83bfee6
--- /dev/null
+++ b/tcg/tcg-helpers.c
@@ -0,0 +1,32 @@
+/*
+ * TCG Common Helper Functions
+ *
+ * Copyright (c) 2014
+ * Written by Alex Benn??e alex.ben...@linaro.org
+ *
+ * This code is licensed under the GNU GPL v2.
+ *
+ * This file contains common non-architecture specific helper
+ * functions that can be used from TCG generated code. Currently these
+ * are mainly helpful for debugging.
+ */
+
+#include stdlib.h
+#include stdio.h
+
+#include cpu.h
+#include exec/exec-all.h
+#include helper.h
+
+/* TCG Value Dumpers */
+uint32_t HELPER(dump_u32)(uint32_t val, void *string)
+{
+fprintf(stderr,%s %x\n, (char *) string, val);
+return val;
+}
+
+uint64_t HELPER(dump_u64)(uint64_t val, void *string)
+{
+fprintf(stderr,%s %lx\n, (char *) string, val);
+return val;
+}
diff --git a/tcg/tcg-helpers.h b/tcg/tcg-helpers.h
new file mode 100644
index 000..510d8b5
--- /dev/null
+++ b/tcg/tcg-helpers.h
@@ -0,0 +1,57 @@
+/*
+ * TCG Common Helpers
+ *
+ * Copyright (c) 2014
+ * Written by Alex Benn??e alex.ben...@linaro.org
+ *
+ * This code is licensed under the GNU GPL v2.
+ *
+ * WARNING: intended to be included in $ARCH/helper.h
+ */
+
+DEF_HELPER_2(dump_u32, i32, i32, ptr)
+DEF_HELPER_2(dump_u64, i64, i64, ptr)
+
+
+/*
+ * Formatting macros
+ *
+ * To be useful we would like to format a string with a message to be
+ * associated with this dump. As these strings have to live the
+ * lifetime of the generated code we are essentially leaking memory so
+ * the more times a given dump call is generated the more memory is
+ * consumed (not so for each time the TCG code itself is called)
+ */
+
+/* This limits the number of malloc'ed strings *per call site* */
+#define TCG_DEBUG_DUMP_MAX_STRINGS 10
+
+/* String macro magic */
+#define STRINGIFY_DETAIL(x) #x
+#define STRINGIFY(x) STRINGIFY_DETAIL(x)
+
+#define tcg_debug_dump_i32(tcg32, fmt, ...)   \
+do {  \
+static int tcg_debug_alloc_strings = 0;   \
+gchar *debug_string = (gchar *) __FILE__ : STRINGIFY(__LINE__) :; \
+TCGv_ptr tcg_string;  \
+if (tcg_debug_alloc_strings++  TCG_DEBUG_DUMP_MAX_STRINGS) { \
+debug_string = g_strdup_printf(fmt :, ## __VA_ARGS__);  \
+} \
+tcg_string = tcg_const_ptr(debug_string); \
+gen_helper_dump_u32(tcg32, tcg32, tcg_string);\
+tcg_temp_free_ptr(tcg_string);\
+} while (0);
+
+#define tcg_debug_dump_i64(tcg64, fmt, ...)   \
+do {  \
+static int tcg_debug_alloc_strings = 0;   \
+gchar *debug_string = (gchar *) __FILE__ : STRINGIFY(__LINE__) :; \
+TCGv_ptr tcg_string;  \
+if (tcg_debug_alloc_strings++  TCG_DEBUG_DUMP_MAX_STRINGS) { \
+debug_string = g_strdup_printf(fmt :, ## __VA_ARGS__);  \
+} \
+tcg_string = tcg_const_ptr(debug_string); \
+gen_helper_dump_u64(tcg64, tcg64, tcg_string);\
+tcg_temp_free_ptr(tcg_string);\
+} while (0);
-- 
1.9.0

[Qemu-devel] [RCF PATCH 1/2] tcg: add tcg_abort_dbg() for additional debug info

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

There are times the tcg aborts with a fatal but terse error which isn't
overly helpful. This adds an alternative macro that can be used to show
a little more helper information when an abort occurs.

diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
index f832282..1a6c565 100644
--- a/tcg/i386/tcg-target.c
+++ b/tcg/i386/tcg-target.c
@@ -1342,7 +1342,7 @@ static void tcg_out_qemu_ld_slow_path(TCGContext *s, 
TCGLabelQemuLdst *l)
 }
 break;
 default:
-tcg_abort();
+tcg_abort_dbg(bad opc:%x, opc);
 }
 
 /* Jump to the code corresponding to next IR of qemu_st */
@@ -1519,7 +1519,7 @@ static void tcg_out_qemu_ld_direct(TCGContext *s, TCGReg 
datalo, TCGReg datahi,
 }
 break;
 default:
-tcg_abort();
+tcg_abort_dbg(bad memop=%x, memop);
 }
 }
 
diff --git a/tcg/optimize.c b/tcg/optimize.c
index 743..ae1a3f8 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -407,7 +407,7 @@ static bool do_constant_folding_cond_eq(TCGCond c)
 case TCG_COND_EQ:
 return 1;
 default:
-tcg_abort();
+tcg_abort_dbg(bad condition:%d, c);
 }
 }
 
diff --git a/tcg/tcg.h b/tcg/tcg.h
index f7efcb4..bfde09f 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -657,12 +657,15 @@ typedef struct TCGTargetOpDef {
 const char *args_ct_str[TCG_MAX_OP_ARGS];
 } TCGTargetOpDef;
 
-#define tcg_abort() \
+#define tcg_abort_dbg(fmt, ...)\
 do {\
-fprintf(stderr, %s:%d: tcg fatal error\n, __FILE__, __LINE__);\
+fprintf(stderr, %s:%d: tcg fatal error  fmt \n,\
+__FILE__, __LINE__, ## __VA_ARGS__);\
 abort();\
 } while (0)
 
+#define tcg_abort() tcg_abort_dbg()
+
 #ifdef CONFIG_DEBUG_TCG
 # define tcg_debug_assert(X) do { assert(X); } while (0)
 #elif QEMU_GNUC_PREREQ(4, 5)
-- 
1.9.0

[Qemu-devel] [PULL 0/4] Travis Updates

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

No changes from the original version posted except to add Stefan's
reviewed-by tags. I thought it was worth submitting this before we
froze for 2.0!

The following changes since commit be813ef02d18ba58e1ff32f1706bcacb88f1f764:

  Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
(2014-03-11 19:52:32 +)

are available in the git repository at:


  g...@github.com:stsquad/qemu.git travis-updates

for you to fetch changes up to 3e6fa9a5bb773d0d7d22d9aea0495d91404dfd3d:

  .travis.yml: add IRC notifications for build failures (2014-03-12 13:52:27 
+)


Alex Bennée (4):
  .travis.yml: add a new build target with non-core devlibs
  .travis.yml: re-enable lttng user space trace test
  .travis.yml: trivial whitespace fixup
  .travis.yml: add IRC notifications for build failures

 .travis.yml | 53 +++--
 1 file changed, 31 insertions(+), 22 deletions(-)

[Qemu-devel] [PULL 1/4] .travis.yml: add a new build target with non-core devlibs

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

The current builds don't include all the features which are
auto-detected and then disabled when the appropriate test packages don't
exist. I've added another target that enables all known additional
packages for increased coverage. I didn't add it to the core package
list to reduce build time.

Signed-off-by: Alex Bennée alex.ben...@linaro.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com

diff --git a/.travis.yml b/.travis.yml
index c7ff4da..286cf62 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -46,6 +46,10 @@ matrix:
 - env: TARGETS=i386-softmmu,x86_64-softmmu
EXTRA_CONFIG=--enable-debug --enable-tcg-interpreter
   compiler: gcc
+# All the extra -dev packages
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_PKGS=libaio-dev libcap-ng-dev libattr1-dev libbrlapi-dev 
uuid-dev libusb-1.0.0-dev
+  compiler: gcc
 # Currently configure doesn't force --disable-pie
 - env: TARGETS=i386-softmmu,x86_64-softmmu
EXTRA_CONFIG=--enable-gprof --enable-gcov --disable-pie
-- 
1.9.0

[Qemu-devel] [PULL 3/4] .travis.yml: trivial whitespace fixup

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

Purely cosmetic but satisfies my OCD.

Signed-off-by: Alex Bennée alex.ben...@linaro.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com

diff --git a/.travis.yml b/.travis.yml
index 1d78421..0dbf2da 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -14,23 +14,23 @@ env:
 - GUI_PKGS=libgtk-3-dev libvte-2.90-dev libsdl1.2-dev libpng12-dev 
libpixman-1-dev
 - EXTRA_PKGS=
   matrix:
-  - TARGETS=alpha-softmmu,alpha-linux-user
-  - TARGETS=arm-softmmu,arm-linux-user
-  - TARGETS=aarch64-softmmu,aarch64-linux-user
-  - TARGETS=cris-softmmu
-  - TARGETS=i386-softmmu,x86_64-softmmu
-  - TARGETS=lm32-softmmu
-  - TARGETS=m68k-softmmu
-  - TARGETS=microblaze-softmmu,microblazeel-softmmu
-  - TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
-  - TARGETS=moxie-softmmu
-  - TARGETS=or32-softmmu,
-  - TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
-  - TARGETS=s390x-softmmu
-  - TARGETS=sh4-softmmu,sh4eb-softmmu
-  - TARGETS=sparc-softmmu,sparc64-softmmu
-  - TARGETS=unicore32-softmmu
-  - TARGETS=xtensa-softmmu,xtensaeb-softmmu
+- TARGETS=alpha-softmmu,alpha-linux-user
+- TARGETS=arm-softmmu,arm-linux-user
+- TARGETS=aarch64-softmmu,aarch64-linux-user
+- TARGETS=cris-softmmu
+- TARGETS=i386-softmmu,x86_64-softmmu
+- TARGETS=lm32-softmmu
+- TARGETS=m68k-softmmu
+- TARGETS=microblaze-softmmu,microblazeel-softmmu
+- TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
+- TARGETS=moxie-softmmu
+- TARGETS=or32-softmmu,
+- TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
+- TARGETS=s390x-softmmu
+- TARGETS=sh4-softmmu,sh4eb-softmmu
+- TARGETS=sparc-softmmu,sparc64-softmmu
+- TARGETS=unicore32-softmmu
+- TARGETS=xtensa-softmmu,xtensaeb-softmmu
 before_install:
   - git submodule update --init --recursive
   - sudo apt-get update -qq
-- 
1.9.0

[Qemu-devel] [PULL 2/4] .travis.yml: re-enable lttng user space trace test

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

This build was disabled while the lttng tracing was broken. Stefan has
recently submitted a pull request with it re-enabled.

Signed-off-by: Alex Bennée alex.ben...@linaro.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com

diff --git a/.travis.yml b/.travis.yml
index 286cf62..1d78421 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -69,8 +69,7 @@ matrix:
EXTRA_CONFIG=--enable-trace-backend=ftrace
TEST_CMD=
   compiler: gcc
-# This disabled make check for the ftrace backend which needs more setting 
up
-# Currently broken on 12.04 due to mis-packaged liburcu and changed API, 
will be pulled.
-#- env: TARGETS=i386-softmmu,x86_64-softmmu
-#   EXTRA_PKGS=liblttng-ust-dev liburcu-dev
-#   EXTRA_CONFIG=--enable-trace-backend=ust
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+  EXTRA_PKGS=liblttng-ust-dev liburcu-dev
+  EXTRA_CONFIG=--enable-trace-backend=ust
+  compiler: gcc
-- 
1.9.0

[Qemu-devel] [PULL 4/4] .travis.yml: add IRC notifications for build failures

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

I'm trying to avoid spamming the IRC channel (not overly likely as
builds take a while). So failure will always be reported but if the
build continues to work then the IRC notifications will be quiet.

Note any GitHub based repository with Travis enabled will use this
notification. If it proves to be too spammy we may want to ask users not
to use Travis themselves although this seems sub-optimal.

Signed-off-by: Alex Bennée alex.ben...@linaro.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com

diff --git a/.travis.yml b/.travis.yml
index 0dbf2da..04da973 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -4,6 +4,12 @@ python:
 compiler:
   - gcc
   - clang
+notifications:
+  irc:
+channels:
+  - irc.oftc.net#qemu
+on_success: change
+on_failure: always
 env:
   global:
 - TEST_CMD=make check
-- 
1.9.0

[Qemu-devel] [RCF PATCH 0/2] Improving TCG debug output

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

Hi,

These two patches have been sitting in my personal tree for a while
and I thought it was worth soliciting feedback as to their wider usefulness.

The first is simply an attempt to make tcg abort failures a little
less terse.

The second I found useful when I was debugging a complex set of TCG
ops for a round, shift and narrow implementation. The alternative was
to set up GDB and step through the generated target code (or just
infer from the copious dumps). The macro magic might be a bit much though.

Alex Bennée (2):
  tcg: add tcg_abort_dbg() for additional debug info
  tcg: add debug helpers tcg_debug_dump_i(32|64)

 Makefile.target   |  2 +-
 target-arm/helper.h   |  2 ++
 tcg/i386/tcg-target.c |  4 ++--
 tcg/optimize.c|  2 +-
 tcg/tcg-helpers.c | 32 +
 tcg/tcg-helpers.h | 57 +++
 tcg/tcg.h |  7 +--
 7 files changed, 100 insertions(+), 6 deletions(-)
 create mode 100644 tcg/tcg-helpers.c
 create mode 100644 tcg/tcg-helpers.h

-- 
1.9.0

[Qemu-devel] [RCF PATCH 2/2] tcg: add debug helpers tcg_debug_dump_i(32|64)

2014-03-12 Thread alex . bennee 
From: Alex Benn??e alex.ben...@linaro.org

The helpers are useful for debugging if you want to inspect interim
values of tcg temp variables while executing TCG generated code. This is
an alternative to tracing with logs or inspecting with GDB.

The functions do take format strings but to prevent massive memory loss
it will default to a constant string after a short number of uses.

 create mode 100644 tcg/tcg-helpers.c
 create mode 100644 tcg/tcg-helpers.h

diff --git a/Makefile.target b/Makefile.target
index ba12340..a87b7d7 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -73,7 +73,7 @@ all: $(PROGS) stap
 #
 # cpu emulator library
 obj-y = exec.o translate-all.o cpu-exec.o
-obj-y += tcg/tcg.o tcg/optimize.o
+obj-y += tcg/tcg.o tcg/optimize.o tcg/tcg-helpers.o
 obj-$(CONFIG_TCG_INTERPRETER) += tci.o
 obj-$(CONFIG_TCG_INTERPRETER) += disas/tci.o
 obj-y += fpu/softfloat.o
diff --git a/target-arm/helper.h b/target-arm/helper.h
index 8923f8a..7600c21 100644
--- a/target-arm/helper.h
+++ b/target-arm/helper.h
@@ -507,4 +507,6 @@ DEF_HELPER_FLAGS_3(crc32c, TCG_CALL_NO_RWG_SE, i32, i32, 
i32, i32)
 #include helper-a64.h
 #endif
 
+#include tcg/tcg-helpers.h
+
 #include exec/def-helper.h
diff --git a/tcg/tcg-helpers.c b/tcg/tcg-helpers.c
new file mode 100644
index 000..83bfee6
--- /dev/null
+++ b/tcg/tcg-helpers.c
@@ -0,0 +1,32 @@
+/*
+ * TCG Common Helper Functions
+ *
+ * Copyright (c) 2014
+ * Written by Alex Benn??e alex.ben...@linaro.org
+ *
+ * This code is licensed under the GNU GPL v2.
+ *
+ * This file contains common non-architecture specific helper
+ * functions that can be used from TCG generated code. Currently these
+ * are mainly helpful for debugging.
+ */
+
+#include stdlib.h
+#include stdio.h
+
+#include cpu.h
+#include exec/exec-all.h
+#include helper.h
+
+/* TCG Value Dumpers */
+uint32_t HELPER(dump_u32)(uint32_t val, void *string)
+{
+fprintf(stderr,%s %x\n, (char *) string, val);
+return val;
+}
+
+uint64_t HELPER(dump_u64)(uint64_t val, void *string)
+{
+fprintf(stderr,%s %lx\n, (char *) string, val);
+return val;
+}
diff --git a/tcg/tcg-helpers.h b/tcg/tcg-helpers.h
new file mode 100644
index 000..510d8b5
--- /dev/null
+++ b/tcg/tcg-helpers.h
@@ -0,0 +1,57 @@
+/*
+ * TCG Common Helpers
+ *
+ * Copyright (c) 2014
+ * Written by Alex Benn??e alex.ben...@linaro.org
+ *
+ * This code is licensed under the GNU GPL v2.
+ *
+ * WARNING: intended to be included in $ARCH/helper.h
+ */
+
+DEF_HELPER_2(dump_u32, i32, i32, ptr)
+DEF_HELPER_2(dump_u64, i64, i64, ptr)
+
+
+/*
+ * Formatting macros
+ *
+ * To be useful we would like to format a string with a message to be
+ * associated with this dump. As these strings have to live the
+ * lifetime of the generated code we are essentially leaking memory so
+ * the more times a given dump call is generated the more memory is
+ * consumed (not so for each time the TCG code itself is called)
+ */
+
+/* This limits the number of malloc'ed strings *per call site* */
+#define TCG_DEBUG_DUMP_MAX_STRINGS 10
+
+/* String macro magic */
+#define STRINGIFY_DETAIL(x) #x
+#define STRINGIFY(x) STRINGIFY_DETAIL(x)
+
+#define tcg_debug_dump_i32(tcg32, fmt, ...)   \
+do {  \
+static int tcg_debug_alloc_strings = 0;   \
+gchar *debug_string = (gchar *) __FILE__ : STRINGIFY(__LINE__) :; \
+TCGv_ptr tcg_string;  \
+if (tcg_debug_alloc_strings++  TCG_DEBUG_DUMP_MAX_STRINGS) { \
+debug_string = g_strdup_printf(fmt :, ## __VA_ARGS__);  \
+} \
+tcg_string = tcg_const_ptr(debug_string); \
+gen_helper_dump_u32(tcg32, tcg32, tcg_string);\
+tcg_temp_free_ptr(tcg_string);\
+} while (0);
+
+#define tcg_debug_dump_i64(tcg64, fmt, ...)   \
+do {  \
+static int tcg_debug_alloc_strings = 0;   \
+gchar *debug_string = (gchar *) __FILE__ : STRINGIFY(__LINE__) :; \
+TCGv_ptr tcg_string;  \
+if (tcg_debug_alloc_strings++  TCG_DEBUG_DUMP_MAX_STRINGS) { \
+debug_string = g_strdup_printf(fmt :, ## __VA_ARGS__);  \
+} \
+tcg_string = tcg_const_ptr(debug_string); \
+gen_helper_dump_u64(tcg64, tcg64, tcg_string);\
+tcg_temp_free_ptr(tcg_string);\
+} while (0);
-- 
1.9.0

[Qemu-devel] [PULL 3/4] .travis.yml: trivial whitespace fixup

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

Purely cosmetic but satisfies my OCD.

Signed-off-by: Alex Bennée alex.ben...@linaro.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com

diff --git a/.travis.yml b/.travis.yml
index 1d78421..0dbf2da 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -14,23 +14,23 @@ env:
 - GUI_PKGS=libgtk-3-dev libvte-2.90-dev libsdl1.2-dev libpng12-dev 
libpixman-1-dev
 - EXTRA_PKGS=
   matrix:
-  - TARGETS=alpha-softmmu,alpha-linux-user
-  - TARGETS=arm-softmmu,arm-linux-user
-  - TARGETS=aarch64-softmmu,aarch64-linux-user
-  - TARGETS=cris-softmmu
-  - TARGETS=i386-softmmu,x86_64-softmmu
-  - TARGETS=lm32-softmmu
-  - TARGETS=m68k-softmmu
-  - TARGETS=microblaze-softmmu,microblazeel-softmmu
-  - TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
-  - TARGETS=moxie-softmmu
-  - TARGETS=or32-softmmu,
-  - TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
-  - TARGETS=s390x-softmmu
-  - TARGETS=sh4-softmmu,sh4eb-softmmu
-  - TARGETS=sparc-softmmu,sparc64-softmmu
-  - TARGETS=unicore32-softmmu
-  - TARGETS=xtensa-softmmu,xtensaeb-softmmu
+- TARGETS=alpha-softmmu,alpha-linux-user
+- TARGETS=arm-softmmu,arm-linux-user
+- TARGETS=aarch64-softmmu,aarch64-linux-user
+- TARGETS=cris-softmmu
+- TARGETS=i386-softmmu,x86_64-softmmu
+- TARGETS=lm32-softmmu
+- TARGETS=m68k-softmmu
+- TARGETS=microblaze-softmmu,microblazeel-softmmu
+- TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
+- TARGETS=moxie-softmmu
+- TARGETS=or32-softmmu,
+- TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
+- TARGETS=s390x-softmmu
+- TARGETS=sh4-softmmu,sh4eb-softmmu
+- TARGETS=sparc-softmmu,sparc64-softmmu
+- TARGETS=unicore32-softmmu
+- TARGETS=xtensa-softmmu,xtensaeb-softmmu
 before_install:
   - git submodule update --init --recursive
   - sudo apt-get update -qq
-- 
1.9.0

[Qemu-devel] [PULL 0/4] Travis Updates

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

No changes from the original version posted except to add Stefan's
reviewed-by tags. I thought it was worth submitting this before we
froze for 2.0!

The following changes since commit be813ef02d18ba58e1ff32f1706bcacb88f1f764:

  Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
(2014-03-11 19:52:32 +)

are available in the git repository at:


  g...@github.com:stsquad/qemu.git travis-updates

for you to fetch changes up to 3e6fa9a5bb773d0d7d22d9aea0495d91404dfd3d:

  .travis.yml: add IRC notifications for build failures (2014-03-12 13:52:27 
+)


Alex Bennée (4):
  .travis.yml: add a new build target with non-core devlibs
  .travis.yml: re-enable lttng user space trace test
  .travis.yml: trivial whitespace fixup
  .travis.yml: add IRC notifications for build failures

 .travis.yml | 53 +++--
 1 file changed, 31 insertions(+), 22 deletions(-)

[Qemu-devel] [PULL 4/4] .travis.yml: add IRC notifications for build failures

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

I'm trying to avoid spamming the IRC channel (not overly likely as
builds take a while). So failure will always be reported but if the
build continues to work then the IRC notifications will be quiet.

Note any GitHub based repository with Travis enabled will use this
notification. If it proves to be too spammy we may want to ask users not
to use Travis themselves although this seems sub-optimal.

Signed-off-by: Alex Bennée alex.ben...@linaro.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com

diff --git a/.travis.yml b/.travis.yml
index 0dbf2da..04da973 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -4,6 +4,12 @@ python:
 compiler:
   - gcc
   - clang
+notifications:
+  irc:
+channels:
+  - irc.oftc.net#qemu
+on_success: change
+on_failure: always
 env:
   global:
 - TEST_CMD=make check
-- 
1.9.0

[Qemu-devel] [PULL 1/4] .travis.yml: add a new build target with non-core devlibs

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

The current builds don't include all the features which are
auto-detected and then disabled when the appropriate test packages don't
exist. I've added another target that enables all known additional
packages for increased coverage. I didn't add it to the core package
list to reduce build time.

Signed-off-by: Alex Bennée alex.ben...@linaro.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com

diff --git a/.travis.yml b/.travis.yml
index c7ff4da..286cf62 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -46,6 +46,10 @@ matrix:
 - env: TARGETS=i386-softmmu,x86_64-softmmu
EXTRA_CONFIG=--enable-debug --enable-tcg-interpreter
   compiler: gcc
+# All the extra -dev packages
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_PKGS=libaio-dev libcap-ng-dev libattr1-dev libbrlapi-dev 
uuid-dev libusb-1.0.0-dev
+  compiler: gcc
 # Currently configure doesn't force --disable-pie
 - env: TARGETS=i386-softmmu,x86_64-softmmu
EXTRA_CONFIG=--enable-gprof --enable-gcov --disable-pie
-- 
1.9.0

[Qemu-devel] [RCF PATCH 1/2] tcg: add tcg_abort_dbg() for additional debug info

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

There are times the tcg aborts with a fatal but terse error which isn't
overly helpful. This adds an alternative macro that can be used to show
a little more helper information when an abort occurs.

diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
index f832282..1a6c565 100644
--- a/tcg/i386/tcg-target.c
+++ b/tcg/i386/tcg-target.c
@@ -1342,7 +1342,7 @@ static void tcg_out_qemu_ld_slow_path(TCGContext *s, 
TCGLabelQemuLdst *l)
 }
 break;
 default:
-tcg_abort();
+tcg_abort_dbg(bad opc:%x, opc);
 }
 
 /* Jump to the code corresponding to next IR of qemu_st */
@@ -1519,7 +1519,7 @@ static void tcg_out_qemu_ld_direct(TCGContext *s, TCGReg 
datalo, TCGReg datahi,
 }
 break;
 default:
-tcg_abort();
+tcg_abort_dbg(bad memop=%x, memop);
 }
 }
 
diff --git a/tcg/optimize.c b/tcg/optimize.c
index 743..ae1a3f8 100644
--- a/tcg/optimize.c
+++ b/tcg/optimize.c
@@ -407,7 +407,7 @@ static bool do_constant_folding_cond_eq(TCGCond c)
 case TCG_COND_EQ:
 return 1;
 default:
-tcg_abort();
+tcg_abort_dbg(bad condition:%d, c);
 }
 }
 
diff --git a/tcg/tcg.h b/tcg/tcg.h
index f7efcb4..bfde09f 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -657,12 +657,15 @@ typedef struct TCGTargetOpDef {
 const char *args_ct_str[TCG_MAX_OP_ARGS];
 } TCGTargetOpDef;
 
-#define tcg_abort() \
+#define tcg_abort_dbg(fmt, ...)\
 do {\
-fprintf(stderr, %s:%d: tcg fatal error\n, __FILE__, __LINE__);\
+fprintf(stderr, %s:%d: tcg fatal error  fmt \n,\
+__FILE__, __LINE__, ## __VA_ARGS__);\
 abort();\
 } while (0)
 
+#define tcg_abort() tcg_abort_dbg()
+
 #ifdef CONFIG_DEBUG_TCG
 # define tcg_debug_assert(X) do { assert(X); } while (0)
 #elif QEMU_GNUC_PREREQ(4, 5)
-- 
1.9.0

[Qemu-devel] [PULL 2/4] .travis.yml: re-enable lttng user space trace test

2014-03-12 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

This build was disabled while the lttng tracing was broken. Stefan has
recently submitted a pull request with it re-enabled.

Signed-off-by: Alex Bennée alex.ben...@linaro.org
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com

diff --git a/.travis.yml b/.travis.yml
index 286cf62..1d78421 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -69,8 +69,7 @@ matrix:
EXTRA_CONFIG=--enable-trace-backend=ftrace
TEST_CMD=
   compiler: gcc
-# This disabled make check for the ftrace backend which needs more setting 
up
-# Currently broken on 12.04 due to mis-packaged liburcu and changed API, 
will be pulled.
-#- env: TARGETS=i386-softmmu,x86_64-softmmu
-#   EXTRA_PKGS=liblttng-ust-dev liburcu-dev
-#   EXTRA_CONFIG=--enable-trace-backend=ust
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+  EXTRA_PKGS=liblttng-ust-dev liburcu-dev
+  EXTRA_CONFIG=--enable-trace-backend=ust
+  compiler: gcc
-- 
1.9.0

[Qemu-devel] [PATCH v1 2/4] .travis.yml: re-enable lttng user space trace test

2014-02-20 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

This build was disabled while the lttng tracing was broken. Stefan has
recently submitted a pull request with it re-enabled.

Signed-off-by: Alex Bennée alex.ben...@linaro.org

diff --git a/.travis.yml b/.travis.yml
index 286cf62..1d78421 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -69,8 +69,7 @@ matrix:
EXTRA_CONFIG=--enable-trace-backend=ftrace
TEST_CMD=
   compiler: gcc
-# This disabled make check for the ftrace backend which needs more setting 
up
-# Currently broken on 12.04 due to mis-packaged liburcu and changed API, 
will be pulled.
-#- env: TARGETS=i386-softmmu,x86_64-softmmu
-#   EXTRA_PKGS=liblttng-ust-dev liburcu-dev
-#   EXTRA_CONFIG=--enable-trace-backend=ust
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+  EXTRA_PKGS=liblttng-ust-dev liburcu-dev
+  EXTRA_CONFIG=--enable-trace-backend=ust
+  compiler: gcc
-- 
1.9.0

[Qemu-devel] [PATCH v1 4/4] .travis.yml: add IRC notifications for build failures

2014-02-20 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

I'm trying to avoid spamming the IRC channel (not overly likely as
builds take a while). So failure will always be reported but if the
build continues to work then the IRC notifications will be quiet.

Note any GitHub based repository with Travis enabled will use this
notification. If it proves to be too spammy we may want to ask users not
to use Travis themselves although this seems sub-optimal.

Signed-off-by: Alex Bennée alex.ben...@linaro.org

diff --git a/.travis.yml b/.travis.yml
index 0dbf2da..04da973 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -4,6 +4,12 @@ python:
 compiler:
   - gcc
   - clang
+notifications:
+  irc:
+channels:
+  - irc.oftc.net#qemu
+on_success: change
+on_failure: always
 env:
   global:
 - TEST_CMD=make check
-- 
1.9.0

[Qemu-devel] [PATCH v1 3/4] .travis.yml: trivial whitespace fixup

2014-02-20 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

Purely cosmetic but satisfies my OCD.

Signed-off-by: Alex Bennée alex.ben...@linaro.org

diff --git a/.travis.yml b/.travis.yml
index 1d78421..0dbf2da 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -14,23 +14,23 @@ env:
 - GUI_PKGS=libgtk-3-dev libvte-2.90-dev libsdl1.2-dev libpng12-dev 
libpixman-1-dev
 - EXTRA_PKGS=
   matrix:
-  - TARGETS=alpha-softmmu,alpha-linux-user
-  - TARGETS=arm-softmmu,arm-linux-user
-  - TARGETS=aarch64-softmmu,aarch64-linux-user
-  - TARGETS=cris-softmmu
-  - TARGETS=i386-softmmu,x86_64-softmmu
-  - TARGETS=lm32-softmmu
-  - TARGETS=m68k-softmmu
-  - TARGETS=microblaze-softmmu,microblazeel-softmmu
-  - TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
-  - TARGETS=moxie-softmmu
-  - TARGETS=or32-softmmu,
-  - TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
-  - TARGETS=s390x-softmmu
-  - TARGETS=sh4-softmmu,sh4eb-softmmu
-  - TARGETS=sparc-softmmu,sparc64-softmmu
-  - TARGETS=unicore32-softmmu
-  - TARGETS=xtensa-softmmu,xtensaeb-softmmu
+- TARGETS=alpha-softmmu,alpha-linux-user
+- TARGETS=arm-softmmu,arm-linux-user
+- TARGETS=aarch64-softmmu,aarch64-linux-user
+- TARGETS=cris-softmmu
+- TARGETS=i386-softmmu,x86_64-softmmu
+- TARGETS=lm32-softmmu
+- TARGETS=m68k-softmmu
+- TARGETS=microblaze-softmmu,microblazeel-softmmu
+- TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
+- TARGETS=moxie-softmmu
+- TARGETS=or32-softmmu,
+- TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
+- TARGETS=s390x-softmmu
+- TARGETS=sh4-softmmu,sh4eb-softmmu
+- TARGETS=sparc-softmmu,sparc64-softmmu
+- TARGETS=unicore32-softmmu
+- TARGETS=xtensa-softmmu,xtensaeb-softmmu
 before_install:
   - git submodule update --init --recursive
   - sudo apt-get update -qq
-- 
1.9.0

[Qemu-devel] [PATCH v1 0/4] Updates for Travis testing

2014-02-20 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

Hi,

I've now enabled Travis testing on the official QEMU GitHub mirror.

Of the following patches two expand the testing, one is a cosmetic
whitespace fix and the final one enabled IRC notification when the
build fails. This is potentially controversial but on balance I think
it would be worth while letting #qemu know as soon as master breaks.
If lots of people start enabling Travis on there own repos then maybe
we would reconsider the notification idea.

As it is build failures should automatically email the author of
${HEAD} as well as the owner of the repo.

There has been interest expressed in running tests on all PULL
requests. One option would be to have some sort of bot (via
patchwork?) push PULL request heads to another GitHub mirror
(qemu-pull-requests.git?) to trigger builds.


Alex Bennée (4):
  .travis.yml: add a new build target with non-core devlibs
  .travis.yml: re-enable lttng user space trace test
  .travis.yml: trivial whitespace fixup
  .travis.yml: add IRC notifications for build failures

 .travis.yml | 53 +++--
 1 file changed, 31 insertions(+), 22 deletions(-)


Cheers,

--
Alex Bennée
QEMU/KVM Hacker for Linaro

[Qemu-devel] [PATCH v1 1/4] .travis.yml: add a new build target with non-core devlibs

2014-02-20 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

The current builds don't include all the features which are
auto-detected and then disabled when the appropriate test packages don't
exist. I've added another target that enables all known additional
packages for increased coverage. I didn't add it to the core package
list to reduce build time.

Signed-off-by: Alex Bennée alex.ben...@linaro.org

diff --git a/.travis.yml b/.travis.yml
index c7ff4da..286cf62 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -46,6 +46,10 @@ matrix:
 - env: TARGETS=i386-softmmu,x86_64-softmmu
EXTRA_CONFIG=--enable-debug --enable-tcg-interpreter
   compiler: gcc
+# All the extra -dev packages
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_PKGS=libaio-dev libcap-ng-dev libattr1-dev libbrlapi-dev 
uuid-dev libusb-1.0.0-dev
+  compiler: gcc
 # Currently configure doesn't force --disable-pie
 - env: TARGETS=i386-softmmu,x86_64-softmmu
EXTRA_CONFIG=--enable-gprof --enable-gcov --disable-pie
-- 
1.9.0

[Qemu-devel] [RFC PATCH 0/0] binfmt script patches

2014-01-08 Thread alex . bennee 
Hi,

While working on my aarch64 work I found setting up binfmt was more of
a pain than it could have been. Specifically:

* hard-coded for /usr/local installs
* no help
* no error checking

Tellingly the script doesn't seem to be used by the distros who have
rolled their own binfmt_misc stuff around qemu. I also found it hard
to figure out why things were not working so I wrote a noddy checker
script for interrogating the state of binfmt.

I'm currently using the -d mode of this script and am running qemu
directly from my source tree (with $HOME bind mounted into my chroot)
and it seems to be working well.

Any comments? Worth pushing some love to the scripts upstream?


Cheers,

--
Alex Bennée
QEMU/KVM Hacker for Linaro

[Qemu-devel] [PATCH 1/2] scripts/qemu-binfmt-conf.sh: re-factor and clean-up

2014-01-08 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

I was looking to set-up for development but found the script made some
hard-coded assumptions. It doesn't seem the script is used by the
distros but if it had a little more love maybe it would be ;-)

* Add usage() instructions
* Move all registering to a single function
* Check for existence of executable qemu before registering
* Add -d (devel) mode for subscribing in-src tree binaries
* error handling when setting binfmt fails
* add support for aarch64
---
 scripts/qemu-binfmt-conf.sh | 124 +---
 1 file changed, 105 insertions(+), 19 deletions(-)
 mode change 100644 = 100755 scripts/qemu-binfmt-conf.sh

diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
old mode 100644
new mode 100755
index 0da2618..8cfb387
--- a/scripts/qemu-binfmt-conf.sh
+++ b/scripts/qemu-binfmt-conf.sh
@@ -1,5 +1,89 @@
 #!/bin/sh
-# enable automatic i386/ARM/M68K/MIPS/SPARC/PPC/s390 program execution by the 
kernel
+# Enable automatic i386/ARM/aarch64/M68K/MIPS/SPARC/PPC/s390
+# program execution by the kernel using the binfmt_misc feature
+#
+
+# Base path for finding QEMU binary
+BINFMT_DEVEL_MODE=
+BINFMT_VERBOSE=
+BINFMT_BASE_PATH=/usr/local/bin
+
+# Print out some simple usage instructions
+usage() {
+echo Usage: `basename $0` options (-hdp)
+echo 
+This script is used to configure binfmt_misc on a system
+to automatically call QEMU when a binary that it can
+deal with is detected by the kernel.
+
+Parameters:
+-p PATH - base path to find QEMU binaries
+  (default: $BINFMT_BASE_PATH)
+-d  - developer mode, search source tree for
+  the QEMU binaries.
+-v  - more verbose output
+
+exit 1
+}
+
+# Register an individual binfmt
+#
+# Before registering the format we check for the
+# existence of the binary and if VERBOSE is set we
+# specify what exactly has been registered.
+
+register_binfmt () {
+name=$1
+qbin=$2
+binfmt_string=$3
+warning=$4
+
+if [ -n ${BINFMT_DEVEL_MODE} ]; then
+qemu_check_path=${BINFMT_BASE_PATH}/${qbin}-linux-user/qemu-${qbin}
+else
+qemu_check_path=${BINFMT_BASE_PATH}/qemu-${qbin}
+fi
+
+if [ -x $qemu_check_path ]; then
+bfmt=:$name:M::$binfmt_string:$qemu_check_path:
+echo $bfmt  /proc/sys/fs/binfmt_misc/register
+res=$?
+if [ $res != 0 ]; then
+echo Error ($res): $bfmt  /proc/sys/fs/binfmt_misc/register
+else
+if [ -n ${BINFMT_VERBOSE} ] ; then
+echo registered $qemu_check_path for $name binaries
+fi
+if [ -n $warning ]; then
+echo $warning
+fi
+fi
+fi
+}
+
+while getopts vhdp: opt
+do
+case $opt in
+h)
+usage
+;;
+p)
+BINFMT_BASE_PATH=$OPTARG
+;;
+d)
+BINFMT_DEVEL_MODE=1
+script_dir=`dirname $0`
+BINFMT_BASE_PATH=`realpath $script_dir/..`
+;;
+v)
+BINFMT_VERBOSE=1
+;;
+*)
+echo Unknown option.
+usage
+;;
+  esac
+done
 
 # load the binfmt_misc module
 if [ ! -d /proc/sys/fs/binfmt_misc ]; then
@@ -31,39 +115,41 @@ esac
 
 # register the interpreter for each cpu except for the native one
 if [ $cpu != i386 ] ; then
-echo 
':i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/local/bin/qemu-i386:'
  /proc/sys/fs/binfmt_misc/register
-echo 
':i486:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x06\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/local/bin/qemu-i386:'
  /proc/sys/fs/binfmt_misc/register
+register_binfmt i386 i386 
\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff
+register_binfmt i486 i386 
\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x06\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff
 fi
 if [ $cpu != alpha ] ; then
-echo 
':alpha:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x26\x90:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/local/bin/qemu-alpha:'
  /proc/sys/fs/binfmt_misc/register
+register_binfmt alpha alpha 
\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x26\x90:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff
 fi
 if [ $cpu != arm ] ; then
-echo   
':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/local/bin/qemu-arm:'

[Qemu-devel] [PATCH 2/2] scripts/qemu-binfmt-check.py: a binfmt checker

2014-01-08 Thread alex . bennee 
From: Alex Bennée alex.ben...@linaro.org

This script allows you to check if a given binary will match against any
of the currently registered binfmts on the system.

---

v2 (ajb):
   - cleaned up whitespace and checkpatch fixes
---
 scripts/qemu-binfmt-check.py | 109 +++
 1 file changed, 109 insertions(+)
 create mode 100755 scripts/qemu-binfmt-check.py

diff --git a/scripts/qemu-binfmt-check.py b/scripts/qemu-binfmt-check.py
new file mode 100755
index 000..c4309a5
--- /dev/null
+++ b/scripts/qemu-binfmt-check.py
@@ -0,0 +1,109 @@
+#!/usr/bin/python
+#
+# binfmt check script
+#
+# Copyright 2014 Linaro
+#
+# Authors:
+#  Alex Bennee alex.ben...@linaro.org
+#
+# This work is licensed under the terms of the GNU GPL, version 2.  See
+# the COPYING file in the top-level directory.
+
+import os
+import re
+import binascii
+
+re_int = re.compile(rinterpreter (.+)$)
+re_off = re.compile(roffset (\d+)$)
+re_magic = re.compile(rmagic ([\dabcdef]+))
+re_mask = re.compile(rmask ([\dabcdef]+))
+
+# argparse is only available in Python = 2.7
+from optparse import OptionParser
+parser = OptionParser()
+
+# list of binfmts
+binfmts = []
+
+
+def read_binfmt_spec(f):
+bfmt = {}
+with open(f) as fd:
+content = fd.readlines()
+for l in content:
+m = re_int.match(l)
+if m:
+bfmt[interpreter] = m.group(1)
+m = re_off.match(l)
+if m:
+bfmt[offset] = int(m.group(1))
+m = re_magic.match(l)
+if m:
+bfmt[magic] = binascii.unhexlify(m.group(1))
+m = re_mask.match(l)
+if m:
+bfmt[mask] = binascii.unhexlify(m.group(1))
+print loaded: %s % bfmt
+binfmts.append(bfmt)
+
+
+def load_binfmt_masks():
+binfmt_dir = /proc/sys/fs/binfmt_misc
+files = os.listdir(binfmt_dir)
+for f in files:
+if not f.startswith(status):
+fp = %s/%s % (binfmt_dir, f)
+if os.access(fp, os.R_OK):
+read_binfmt_spec(fp)
+
+
+def check_file_against_binfmt(fmt, f):
+
+Check if a file will match a given binfmt mask
+
+print checking %s % (f)
+nbytes = len(fmt[magic])
+
+fd = open(f, rb)
+fd.seek(fmt[offset])
+header = fd.read(nbytes)
+magic = fmt[magic]
+try:
+mask = fmt[mask]
+except:
+# TODO, make full mask
+return
+
+values = zip(mask, magic, header)
+failed = False
+pos = 0
+for m, g, h in values:
+mask = ord(m)
+bits_to_check = ord(h)  mask
+magic = ord(g)
+if not bits_to_check == magic:
+print failed at %d (%x, %x, %x) % (pos, mask, magic, 
bits_to_check)
+failed = True
+break
+pos += 1
+return not failed
+
+
+def check_file_against_all_binfmts(f):
+
+Check a file against the binfmt masks
+
+path = os.path.abspath(f)
+print file is %s % (path)
+for b in binfmts:
+if check_file_against_binfmt(b, path):
+print %s will use %s % (path, b[interpreter])
+break
+
+
+if __name__ == __main__:
+(opts, args) = parser.parse_args()
+load_binfmt_masks()
+for f in args:
+check_file_against_all_binfmts(f)
-- 
1.8.5.2

[Qemu-devel] [PATCH v6] .travis.yml: basic compile and check recipes

2013-11-06 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

This adds a build matrix definition for travis-ci.org continuous
integration service. It is usable on any public repository hosted on
GitHub. Once you have created an account signed into Travis you can
enable it on selected projects via travis-ci.org/profile. Alternatively
you can configure the service hooks on GitHub via the repository
Settings tab,then Service Hooks and selecting Travis.

Once setup Travis will automatically test every push as well as any pull
requests submitted to that repository.

The build matrix is currently split by target architecture (see TARGETS
environment variable) because a full build of QEMU can take some time.
This way you get quick feedback for any obvious errors. The additional
environment variables exist to allow additional builds to tweak the
environment. These are:

EXTRA_CONFIG - extra terms passed to configure
EXTRA_PKGS - extra dev packages to install
TEST_CMD - default make check, can be overridden

I've confined the additional stuff to x86/x86_64 for convenience.

As Travis supports clang the main builds are done twice (once for gcc
and once for clang). However clang is disabled for the debug/trace
builds for the purposes of brevity.

Other wrinkles:

 * The lttng user-space tracing back-end is disabled
   (it is currently horribly broken)
 * The ftrace back-end doesn't run make check
   (it requires a mounted debugfs to work)
 * There are two debug enabled build (with and without TCG interpreter)

Signed-off-by: Alex Bennée a...@bennee.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
---
 .travis.yml | 71 +
 1 file changed, 71 insertions(+)
 create mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..6e60d84
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,71 @@
+language: c
+python:
+  - 2.4
+compiler:
+  - gcc
+  - clang
+env:
+  global:
+- TEST_CMD=make check
+- EXTRA_CONFIG=
+# Development packages, EXTRA_PKGS saved for additional builds
+- CORE_PKGS=libusb-1.0-0-dev libiscsi-dev librados-dev libncurses5-dev
+- NET_PKGS=libseccomp-dev libgnutls-dev libssh2-1-dev  
libspice-server-dev libspice-protocol-dev libnss3-dev
+- GUI_PKGS=libgtk-3-dev libvte-2.90-dev libsdl1.2-dev libpng12-dev 
libpixman-1-dev
+- EXTRA_PKGS=
+  matrix:
+  - TARGETS=alpha-softmmu,alpha-linux-user
+  - TARGETS=arm-softmmu,arm-linux-user
+  - TARGETS=cris-softmmu
+  - TARGETS=i386-softmmu,x86_64-softmmu
+  - TARGETS=lm32-softmmu
+  - TARGETS=m68k-softmmu 
+  - TARGETS=microblaze-softmmu,microblazeel-softmmu
+  - TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
+  - TARGETS=moxie-softmmu
+  - TARGETS=or32-softmmu,
+  - TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
+  - TARGETS=s390x-softmmu
+  - TARGETS=sh4-softmmu,sh4eb-softmmu
+  - TARGETS=sparc-softmmu,sparc64-softmmu
+  - TARGETS=unicore32-softmmu
+  - TARGETS=xtensa-softmmu,xtensaeb-softmmu
+before_install:
+  - git submodule update --init --recursive
+  - sudo apt-get update -qq
+  - sudo apt-get install -qq ${CORE_PKGS} ${NET_PKGS} ${GUI_PKGS} ${EXTRA_PKGS}
+script: ./configure --target-list=${TARGETS} ${EXTRA_CONFIG}  make  
${TEST_CMD}
+matrix:
+  # We manually include a number of additional build for non-standard bits
+  include:
+# Debug related options
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-debug
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-debug --enable-tcg-interpreter
+  compiler: gcc
+# Currently configure doesn't force --disable-pie
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-gprof --enable-gcov --disable-pie
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_PKGS=sparse
+   EXTRA_CONFIG=--enable-sparse
+  compiler: gcc
+# All the trace backends (apart from dtrace)
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=stderr
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=simple
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=ftrace
+   TEST_CMD=
+  compiler: gcc
+# This disabled make check for the ftrace backend which needs more setting 
up
+# Currently broken on 12.04 due to mis-packaged liburcu and changed API, 
will be pulled.
+#- env: TARGETS=i386-softmmu,x86_64-softmmu
+#   EXTRA_PKGS=liblttng-ust-dev liburcu-dev
+#   EXTRA_CONFIG=--enable-trace-backend=ust
-- 
1.8.4.2

[Qemu-devel] [PATCH v6] Add .travis.yml metadata for CI

2013-11-06 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

Hi,

I think this patch is ready to be merged via trivial. While I was
testing it last night it caught yet another regression
(register_subpage: Assertion, since fixed) so I think it proves it's
worth with that alone.

Since v5
  - Forced the python to 2.4 (our current baseline python)

Alex Bennée (1):
  .travis.yml: basic compile and check recipes

 .travis.yml | 71 +
 1 file changed, 71 insertions(+)
 create mode 100644 .travis.yml

-- 
1.8.4.2

[Qemu-devel] [PATCH v4] integrator: fix Linux boot failure by emulating dbg region

2013-10-22 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

Commit 9b8c69243 (since reverted) broke the ability to boot the kernel
as the value returned by unassigned_mem_read returned non-zero and left
the kernel looping forever waiting for it to change (see
integrator_led_set in the kernel code).

Relying on a varying implementation detail is incorrect anyway so this
introduces a basic stub of a memory region for the debug/LED section
on the integrator board.

Signed-off-by: Alex Bennée a...@bennee.com
---

Changes for v4:
 * Moved hw/arm/integrator_debug.c - hw/misc/arm_integrator_debug.c

 default-configs/arm-softmmu.mak|   1 +
 hw/arm/integratorcp.c  |   2 +
 hw/misc/Makefile.objs  |   1 +
 hw/misc/arm_integrator_debug.c | 103 +
 include/hw/misc/arm_integrator_debug.h |  18 ++
 5 files changed, 125 insertions(+)
 create mode 100644 hw/misc/arm_integrator_debug.c
 create mode 100644 include/hw/misc/arm_integrator_debug.h

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index d13bc2b..7e69137 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -79,3 +79,4 @@ CONFIG_VERSATILE_PCI=y
 CONFIG_VERSATILE_I2C=y
 
 CONFIG_SDHCI=y
+CONFIG_INTEGRATOR_DEBUG=y
diff --git a/hw/arm/integratorcp.c b/hw/arm/integratorcp.c
index 2ef93ed..c44b2a4 100644
--- a/hw/arm/integratorcp.c
+++ b/hw/arm/integratorcp.c
@@ -11,6 +11,7 @@
 #include hw/devices.h
 #include hw/boards.h
 #include hw/arm/arm.h
+#include hw/misc/arm_integrator_debug.h
 #include net/net.h
 #include exec/address-spaces.h
 #include sysemu/sysemu.h
@@ -508,6 +509,7 @@ static void integratorcp_init(QEMUMachineInitArgs *args)
 icp_control_init(0xcb00);
 sysbus_create_simple(pl050_keyboard, 0x1800, pic[3]);
 sysbus_create_simple(pl050_mouse, 0x1900, pic[4]);
+sysbus_create_simple(TYPE_INTEGRATOR_DEBUG, 0x1a00, 0);
 sysbus_create_varargs(pl181, 0x1c00, pic[23], pic[24], NULL);
 if (nd_table[0].used)
 smc91c111_init(nd_table[0], 0xc800, pic[27]);
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 2578e29..cca5c05 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -10,6 +10,7 @@ obj-$(CONFIG_VMPORT) += vmport.o
 
 # ARM devices
 common-obj-$(CONFIG_PL310) += arm_l2x0.o
+common-obj-$(CONFIG_INTEGRATOR_DEBUG) += arm_integrator_debug.o
 
 # PKUnity SoC devices
 common-obj-$(CONFIG_PUV3) += puv3_pm.o
diff --git a/hw/misc/arm_integrator_debug.c b/hw/misc/arm_integrator_debug.c
new file mode 100644
index 000..f1ebdd4
--- /dev/null
+++ b/hw/misc/arm_integrator_debug.c
@@ -0,0 +1,103 @@
+/*
+ * LED, Switch and Debug control registers for ARM Integrator Boards
+ *
+ * This is currently a stub for this functionality but at least
+ * ensures something other than unassigned_mem_read() handles access
+ * to this area.
+ *
+ * The real h/w is described at:
+ *  
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0159b/Babbfijf.html
+ *
+ * Copyright (c) 2013 Alex Bennée a...@bennee.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include hw/hw.h
+#include hw/sysbus.h
+#include exec/address-spaces.h
+#include hw/misc/arm_integrator_debug.h
+
+#define INTEGRATOR_DEBUG(obj) \
+OBJECT_CHECK(IntegratorDebugState, (obj), TYPE_INTEGRATOR_DEBUG)
+
+typedef struct {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+
+uint32_t alpha;
+uint32_t leds;
+uint32_t switches;
+} IntegratorDebugState;
+
+static uint64_t intdbg_control_read(void *opaque, hwaddr offset,
+unsigned size)
+{
+switch (offset  2) {
+case 0: /* ALPHA */
+case 1: /* LEDS */
+case 2: /* SWITCHES */
+qemu_log_mask(LOG_UNIMP,
+  %s: returning zero from % HWADDR_PRIx :%u\n,
+  __func__, offset, size);
+return 0;
+default:
+qemu_log_mask(LOG_GUEST_ERROR,
+  %s: Bad offset % HWADDR_PRIx,
+  __func__, offset);
+return 0;
+}
+}
+
+static void intdbg_control_write(void *opaque, hwaddr offset,
+ uint64_t value, unsigned size)
+{
+switch (offset  2) {
+case 1: /* ALPHA */
+case 2: /* LEDS */
+case 3: /* SWITCHES */
+/* Nothing interesting implemented yet.  */
+qemu_log_mask(LOG_UNIMP,
+  %s: ignoring write of % PRIu64
+   to % HWADDR_PRIx :%u\n,
+  __func__, value, offset, size);
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR,
+  %s: write of % PRIu64
+   to bad offset % HWADDR_PRIx \n,
+  __func__, value, offset);
+}
+}
+
+static const MemoryRegionOps intdbg_control_ops = {
+.read = intdbg_control_read,
+

[Qemu-devel] [PATCH v3 0/1] integrator: fix Linux boot failure

2013-10-18 Thread alex . bennee 
From Alex Bennée alex.ben...@linaro.org # This line is ignored.
Hi,

I finally got a chance to follow up on the review comments from Peter
and Andreas.

Changes for v3:

* Moved into hw/arm/integrator_debug.c
* Expanded QOM symbol to INTEGRATOR_DEBUG, moved to header
* Use __func__, HWADDR_PRIx and PRIu64 for debug output
* Add copyright statements
* Fixed line lengths

Cheers,

Alex.

[Qemu-devel] [PATCH v3] integrator: fix Linux boot failure by emulating dbg region

2013-10-18 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

Commit 9b8c69243 (since reverted) broke the ability to boot the kernel
as the value returned by unassigned_mem_read returned non-zero and left
the kernel looping forever waiting for it to change (see
integrator_led_set in the kernel code).

Relying on a varying implementation detail is incorrect anyway so this
introduces a basic stub of a memory region for the debug/LED section
on the integrator board.

Signed-off-by: Alex Bennée a...@bennee.com
---
 hw/arm/Makefile.objs  |   3 +-
 hw/arm/integrator_debug.c | 103 ++
 hw/arm/integratorcp.c |   2 +
 include/hw/arm/integrator_debug.h |  18 +++
 4 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 hw/arm/integrator_debug.c
 create mode 100644 include/hw/arm/integrator_debug.h

diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 3671b42..ffdf7ee 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -1,5 +1,6 @@
 obj-y += boot.o collie.o exynos4_boards.o gumstix.o highbank.o
-obj-y += integratorcp.o kzm.o mainstone.o musicpal.o nseries.o
+obj-y += integratorcp.o integrator_debug.o
+obj-y += kzm.o mainstone.o musicpal.o nseries.o
 obj-y += omap_sx1.o palm.o realview.o spitz.o stellaris.o
 obj-y += tosa.o versatilepb.o vexpress.o xilinx_zynq.o z2.o
 
diff --git a/hw/arm/integrator_debug.c b/hw/arm/integrator_debug.c
new file mode 100644
index 000..c9dd7f0
--- /dev/null
+++ b/hw/arm/integrator_debug.c
@@ -0,0 +1,103 @@
+/*
+ * LED, Switch and Debug control registers for ARM Integrator Boards
+ *
+ * This is currently a stub for this functionality but at least
+ * ensures something other than unassigned_mem_read() handles access
+ * to this area.
+ *
+ * The real h/w is described at:
+ *  
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0159b/Babbfijf.html
+ *
+ * Copyright (c) 2013 Alex Bennée a...@bennee.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include hw/hw.h
+#include hw/sysbus.h
+#include exec/address-spaces.h
+#include hw/arm/integrator_debug.h
+
+#define INTEGRATOR_DEBUG(obj) \
+OBJECT_CHECK(IntegratorDebugState, (obj), TYPE_INTEGRATOR_DEBUG)
+
+typedef struct {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+
+uint32_t alpha;
+uint32_t leds;
+uint32_t switches;
+} IntegratorDebugState;
+
+static uint64_t intdbg_control_read(void *opaque, hwaddr offset,
+unsigned size)
+{
+switch (offset  2) {
+case 0: /* ALPHA */
+case 1: /* LEDS */
+case 2: /* SWITCHES */
+qemu_log_mask(LOG_UNIMP,
+  %s: returning zero from % HWADDR_PRIx :%u\n,
+  __func__, offset, size);
+return 0;
+default:
+qemu_log_mask(LOG_GUEST_ERROR,
+  %s: Bad offset % HWADDR_PRIx,
+  __func__, offset);
+return 0;
+}
+}
+
+static void intdbg_control_write(void *opaque, hwaddr offset,
+ uint64_t value, unsigned size)
+{
+switch (offset  2) {
+case 1: /* ALPHA */
+case 2: /* LEDS */
+case 3: /* SWITCHES */
+/* Nothing interesting implemented yet.  */
+qemu_log_mask(LOG_UNIMP,
+  %s: ignoring write of % PRIu64
+   to % HWADDR_PRIx :%u\n,
+  __func__, value, offset, size);
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR,
+  %s: write of % PRIu64
+   to bad offset % HWADDR_PRIx \n,
+  __func__, value, offset);
+}
+}
+
+static const MemoryRegionOps intdbg_control_ops = {
+.read = intdbg_control_read,
+.write = intdbg_control_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void intdbg_control_init(Object *obj)
+{
+SysBusDevice *sd = SYS_BUS_DEVICE(obj);
+IntegratorDebugState *s = INTEGRATOR_DEBUG(obj);
+
+memory_region_init_io(s-iomem, NULL, intdbg_control_ops,
+  NULL, dbg-leds, 0x100);
+sysbus_init_mmio(sd, s-iomem);
+}
+
+static const TypeInfo intdbg_info = {
+.name  = TYPE_INTEGRATOR_DEBUG,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(IntegratorDebugState),
+.instance_init = intdbg_control_init,
+};
+
+static void intdbg_register_types(void)
+{
+type_register_static(intdbg_info);
+}
+
+type_init(intdbg_register_types)
diff --git a/hw/arm/integratorcp.c b/hw/arm/integratorcp.c
index 2ef93ed..0b2ac2c 100644
--- a/hw/arm/integratorcp.c
+++ b/hw/arm/integratorcp.c
@@ -11,6 +11,7 @@
 #include hw/devices.h
 #include hw/boards.h
 #include hw/arm/arm.h
+#include hw/arm/integrator_debug.h
 #include net/net.h
 #include exec/address-spaces.h
 #include sysemu/sysemu.h
@@ -508,6 +509,7 @@ static void integratorcp_init(QEMUMachineInitArgs

[Qemu-devel] [PATCH] .travis.yml: basic compile and check recipes

2013-10-15 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

This adds a build matrix definition for travis-ci.org continuous
integration service. It is usable on any public repository hosted on
GitHub. Once you have created an account signed into Travis you can
enable it on selected projects via travis-ci.org/profile. Alternatively
you can configure the service hooks on GitHub via the repository
Settings tab,then Service Hooks and selecting Travis.

Once setup Travis will automatically test every push as well as any pull
requests submitted to that repository.

The build matrix is currently split by target architecture (see TARGETS
environment variable) because a full build of QEMU can take some time.
This way you get quick feedback for any obvious errors. The additional
environment variables exist to allow additional builds to tweak the
environment. These are:

EXTRA_CONFIG - extra terms passed to configure
EXTRA_PKGS - extra dev packages to install
TEST_CMD - default make check, can be overridden

I've confined the additional stuff to x86/x86_64 for convenience.

As Travis supports clang the main builds are done twice (once for gcc
and once for clang). However clang is disabled for the debug/trace
builds for the purposes of brevity.

Other wrinkles:

 * The lttng user-space tracing back-end is disabled
   (it is currently horribly broken)
 * The ftrace back-end doesn't run make check
   (it requires a mounted debugfs to work)
 * There are two debug enabled build (with and without TCG interpreter)

Signed-off-by: Alex Bennée a...@bennee.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
---
 .travis.yml | 69 +
 1 file changed, 69 insertions(+)
 create mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..15d36b1
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,69 @@
+language: c
+compiler:
+  - gcc
+  - clang
+env:
+  global:
+- TEST_CMD=make check
+- EXTRA_CONFIG=
+# Development packages, EXTRA_PKGS saved for additional builds
+- CORE_PKGS=libusb-1.0-0-dev libiscsi-dev librados-dev libncurses5-dev
+- NET_PKGS=libseccomp-dev libgnutls-dev libssh2-1-dev  
libspice-server-dev libspice-protocol-dev libnss3-dev
+- GUI_PKGS=libgtk-3-dev libvte-2.90-dev libsdl1.2-dev libpng12-dev 
libpixman-1-dev
+- EXTRA_PKGS=
+  matrix:
+  - TARGETS=alpha-softmmu,alpha-linux-user
+  - TARGETS=arm-softmmu,arm-linux-user
+  - TARGETS=cris-softmmu
+  - TARGETS=i386-softmmu,x86_64-softmmu
+  - TARGETS=lm32-softmmu
+  - TARGETS=m68k-softmmu 
+  - TARGETS=microblaze-softmmu,microblazeel-softmmu
+  - TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
+  - TARGETS=moxie-softmmu
+  - TARGETS=or32-softmmu,
+  - TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
+  - TARGETS=s390x-softmmu
+  - TARGETS=sh4-softmmu,sh4eb-softmmu
+  - TARGETS=sparc-softmmu,sparc64-softmmu
+  - TARGETS=unicore32-softmmu
+  - TARGETS=xtensa-softmmu,xtensaeb-softmmu
+before_install:
+  - git submodule update --init --recursive
+  - sudo apt-get update -qq
+  - sudo apt-get install -qq ${CORE_PKGS} ${NET_PKGS} ${GUI_PKGS} ${EXTRA_PKGS}
+script: ./configure --target-list=${TARGETS} ${EXTRA_CONFIG}  make  
${TEST_CMD}
+matrix:
+  # We manually include a number of additional build for non-standard bits
+  include:
+# Debug related options
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-debug
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-debug --enable-tcg-interpreter
+  compiler: gcc
+# Currently configure doesn't force --disable-pie
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-gprof --enable-gcov --disable-pie
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_PKGS=sparse
+   EXTRA_CONFIG=--enable-sparse
+  compiler: gcc
+# All the trace backends (apart from dtrace)
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=stderr
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=simple
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=ftrace
+   TEST_CMD=
+  compiler: gcc
+# This disabled make check for the ftrace backend which needs more setting 
up
+# Currently broken on 12.04 due to mis-packaged liburcu and changed API, 
will be pulled.
+#- env: TARGETS=i386-softmmu,x86_64-softmmu
+#   EXTRA_PKGS=liblttng-ust-dev liburcu-dev
+#   EXTRA_CONFIG=--enable-trace-backend=ust
-- 
1.8.4

[Qemu-devel] [PULL v5 0/0] .travis.yml: basic compile and check recipies

2013-10-15 Thread alex . bennee 
Hi Anthony,

Here is my first pull request to add a simple .travis.yml profile to the
code base. I'm hoping to expand the range of testing once this is merged
(the tcg code gen tests are next on my list). However as it stands this
already catches build failures and regressions.

Since v4:
  - dropped SeaBIOS patch

Cheers,

Alex

The following changes since commit 1680d485777ecf436d724631ea8722cc0c66990e:

  Merge remote-tracking branch 'rth/tcg-ldst-6' into staging (2013-10-14 
09:59:59 -0700)

are available in the git repository at:


  http://github.com/stsquad/qemu.git travis-ci

for you to fetch changes up to 90878d2c083629a4ee99b2d03158838b35e218c3:

  .travis.yml: basic compile and check recipes (2013-10-15 10:00:10 +0100)


Alex Bennée (1):
  .travis.yml: basic compile and check recipes

 .travis.yml | 69 +
 1 file changed, 69 insertions(+)
 create mode 100644 .travis.yml

[Qemu-devel] [PATCH 2/2] .gitmodules: use upstream SeaBIOS repo to fix submodule init

2013-10-03 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

Currently master is broken as the wanted commit doesn't exist in
qemu's mirror of SeaBIOS.
---
 .gitmodules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitmodules b/.gitmodules
index d7e3f3c..d5d5417 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -3,7 +3,7 @@
url = git://git.qemu.org/vgabios.git/
 [submodule roms/seabios]
path = roms/seabios
-   url = git://git.qemu.org/seabios.git/
+   url = git://git.seabios.org/seabios.git
 [submodule roms/SLOF]
path = roms/SLOF
url = git://git.qemu.org/SLOF.git
-- 
1.8.4

[Qemu-devel] [PATCH 1/2] .travis.yml: basic compile and check recipes

2013-10-03 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

This adds a build matrix definition for travis-ci.org continuous
integration service. It is usable on any public repository hosted on
GitHub. Once you have created an account signed into Travis you can
enable it on selected projects via travis-ci.org/profile. Alternatively
you can configure the service hooks on GitHub via the repository
Settings tab,then Service Hooks and selecting Travis.

Once setup Travis will automatically test every push as well as any pull
requests submitted to that repository.

The build matrix is currently split by target architecture (see TARGETS
environment variable) because a full build of QEMU can take some time.
This way you get quick feedback for any obvious errors. The additional
environment variables exist to allow additional builds to tweak the
environment. These are:

EXTRA_CONFIG - extra terms passed to configure
EXTRA_PKGS - extra dev packages to install
TEST_CMD - default make check, can be overridden

I've confined the additional stuff to x86/x86_64 for convenience.

As Travis supports clang the main builds are done twice (once for gcc
and once for clang). However clang is disabled for the debug/trace
builds for the purposes of brevity.

Other wrinkles:

 * The lttng user-space tracing back-end is disabled
   (it is currently horribly broken)
 * The ftrace back-end doesn't run make check
   (it requires a mounted debugfs to work)
 * There are two debug enabled build (with and without TCG interpreter)

Signed-off-by: Alex Bennée a...@bennee.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
---
 .travis.yml | 69 +
 1 file changed, 69 insertions(+)
 create mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..15d36b1
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,69 @@
+language: c
+compiler:
+  - gcc
+  - clang
+env:
+  global:
+- TEST_CMD=make check
+- EXTRA_CONFIG=
+# Development packages, EXTRA_PKGS saved for additional builds
+- CORE_PKGS=libusb-1.0-0-dev libiscsi-dev librados-dev libncurses5-dev
+- NET_PKGS=libseccomp-dev libgnutls-dev libssh2-1-dev  
libspice-server-dev libspice-protocol-dev libnss3-dev
+- GUI_PKGS=libgtk-3-dev libvte-2.90-dev libsdl1.2-dev libpng12-dev 
libpixman-1-dev
+- EXTRA_PKGS=
+  matrix:
+  - TARGETS=alpha-softmmu,alpha-linux-user
+  - TARGETS=arm-softmmu,arm-linux-user
+  - TARGETS=cris-softmmu
+  - TARGETS=i386-softmmu,x86_64-softmmu
+  - TARGETS=lm32-softmmu
+  - TARGETS=m68k-softmmu 
+  - TARGETS=microblaze-softmmu,microblazeel-softmmu
+  - TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
+  - TARGETS=moxie-softmmu
+  - TARGETS=or32-softmmu,
+  - TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
+  - TARGETS=s390x-softmmu
+  - TARGETS=sh4-softmmu,sh4eb-softmmu
+  - TARGETS=sparc-softmmu,sparc64-softmmu
+  - TARGETS=unicore32-softmmu
+  - TARGETS=xtensa-softmmu,xtensaeb-softmmu
+before_install:
+  - git submodule update --init --recursive
+  - sudo apt-get update -qq
+  - sudo apt-get install -qq ${CORE_PKGS} ${NET_PKGS} ${GUI_PKGS} ${EXTRA_PKGS}
+script: ./configure --target-list=${TARGETS} ${EXTRA_CONFIG}  make  
${TEST_CMD}
+matrix:
+  # We manually include a number of additional build for non-standard bits
+  include:
+# Debug related options
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-debug
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-debug --enable-tcg-interpreter
+  compiler: gcc
+# Currently configure doesn't force --disable-pie
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-gprof --enable-gcov --disable-pie
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_PKGS=sparse
+   EXTRA_CONFIG=--enable-sparse
+  compiler: gcc
+# All the trace backends (apart from dtrace)
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=stderr
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=simple
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=ftrace
+   TEST_CMD=
+  compiler: gcc
+# This disabled make check for the ftrace backend which needs more setting 
up
+# Currently broken on 12.04 due to mis-packaged liburcu and changed API, 
will be pulled.
+#- env: TARGETS=i386-softmmu,x86_64-softmmu
+#   EXTRA_PKGS=liblttng-ust-dev liburcu-dev
+#   EXTRA_CONFIG=--enable-trace-backend=ust
-- 
1.8.4

[Qemu-devel] [PATCH v4 0/0] .travis.yml: basic compile and check recipies and minor fixes

2013-10-03 Thread alex . bennee 
Hi,

While testing after Peter's review comments Travis detected a
regression in the tree due to the updating of SeaBIOS (also found by a
bunch of others in the following days) which I take to be a good
indication of the usefulness of these tests.

v4:
  - split debug build for with/without TCG interpreter
  - add simple patch to use SeaBIOS upstream repo
  - I've left ust commented out, there are patches to remove/replace
  it pending on the mailing list.

Alex Bennée (2):
  .travis.yml: basic compile and check recipes
  .gitmodules: use upstream SeaBIOS repo to fix submodule init

 .gitmodules |  2 +-
 .travis.yml | 69 
+
 2 files changed, 70 insertions(+), 1 deletion(-)

[Qemu-devel] [PATCH] .travis.yml: basic compile and check recipes

2013-09-24 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

This adds a build matrix definition for travis-ci.org continuous
integration service. It is usable on any public repository hosted on
GitHub. Once you have created an account signed into Travis you can
enable it on selected projects via travis-ci.org/profile. Alternatively
you can configure the service hooks on GitHub via the repository
Settings tab,then Service Hooks and selecting Travis.

Once setup Travis will automatically test every push as well as any pull
requests submitted to that repository.

The build matrix is currently split by target architecture (see TARGETS
environment variable) because a full build of QEMU can take some time.
This way you get quick feedback for any obvious errors. The additional
environment variables exist to allow additional builds to tweak the
environment. These are:

EXTRA_CONFIG - extra terms passed to configure
EXTRA_PKGS - extra dev packages to install
TEST_CMD - default make check, can be overridden

I've confined the additional stuff to x86/x86_64 for convenience.

As Travis supports clang the main builds are done twice (once for gcc
and once for clang). However clang is disabled for the debug/trace
builds for the purposes of brevity.

Other wrinkles:

 * The lttng user-space tracing back-end is disabled
   (it is currently horribly broken)
 * The ftrace back-end doesn't run make check
   (it requires a mounted debugfs to work)

Signed-off-by: Alex Bennée a...@bennee.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
---
 .travis.yml | 66 +
 1 file changed, 66 insertions(+)
 create mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..89423ad
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,66 @@
+language: c
+compiler:
+  - gcc
+  - clang
+env:
+  global:
+- TEST_CMD=make check
+- EXTRA_CONFIG=
+# Development packages, EXTRA_PKGS saved for additional builds
+- CORE_PKGS=libusb-1.0-0-dev libiscsi-dev librados-dev libncurses5-dev
+- NET_PKGS=libseccomp-dev libgnutls-dev libssh2-1-dev  
libspice-server-dev libspice-protocol-dev libnss3-dev
+- GUI_PKGS=libgtk-3-dev libvte-2.90-dev libsdl1.2-dev libpng12-dev 
libpixman-1-dev
+- EXTRA_PKGS=
+  matrix:
+  - TARGETS=alpha-softmmu,alpha-linux-user
+  - TARGETS=arm-softmmu,arm-linux-user
+  - TARGETS=cris-softmmu
+  - TARGETS=i386-softmmu,x86_64-softmmu
+  - TARGETS=lm32-softmmu
+  - TARGETS=m68k-softmmu 
+  - TARGETS=microblaze-softmmu,microblazeel-softmmu
+  - TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
+  - TARGETS=moxie-softmmu
+  - TARGETS=or32-softmmu,
+  - TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
+  - TARGETS=s390x-softmmu
+  - TARGETS=sh4-softmmu,sh4eb-softmmu
+  - TARGETS=sparc-softmmu,sparc64-softmmu
+  - TARGETS=unicore32-softmmu
+  - TARGETS=xtensa-softmmu,xtensaeb-softmmu
+before_install:
+  - git submodule update --init --recursive
+  - sudo apt-get update -qq
+  - sudo apt-get install -qq ${CORE_PKGS} ${NET_PKGS} ${GUI_PKGS} ${EXTRA_PKGS}
+script: ./configure --target-list=${TARGETS} ${EXTRA_CONFIG}  make  
${TEST_CMD}
+matrix:
+  # We manually include a number of additional build for non-standard bits
+  include:
+# Debug related options
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-debug --enable-debug-tcg 
--enable-tcg-interpreter
+  compiler: gcc
+# Currently configure doesn't force --disable-pie
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-gprof --enable-gcov --disable-pie
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_PKGS=sparse
+   EXTRA_CONFIG=--enable-sparse
+  compiler: gcc
+# All the trace backends (apart from dtrace)
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=stderr
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=simple
+  compiler: gcc
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=ftrace
+   TEST_CMD=
+  compiler: gcc
+# This disabled make check for the ftrace backend which needs more setting 
up
+# Currently broken on 12.04 due to mis-packaged liburcu and changed API, 
will be pulled.
+#- env: TARGETS=i386-softmmu,x86_64-softmmu
+#   EXTRA_PKGS=liblttng-ust-dev liburcu-dev
+#   EXTRA_CONFIG=--enable-trace-backend=ust
-- 
1.8.4

[Qemu-devel] [PATCH v3 0/0] .travis.yml: basic compile and check recipies

2013-09-24 Thread alex . bennee 
Assuming there are no further comments from this submission I shall
likely make my next posting a PULL request.

v3
  - re-based on current origin/master
  - squashed all .travis commits and re-worded commit
  - added clang builds
  - disabled make check for ftrace back-end
  - fixed broken build due to errant space
  - added Reviewed-by tag for Stefans review

--
Alex Bennée

[Qemu-devel] [PATCH v2 0/0] .travis and minor compile fixes

2013-09-23 Thread alex . bennee 
Hi,

I've updated the .travis.yml following feedback from Stefan to greatly
increase the number of compiles it does. In the process:

* Disabled ust backend (horribly broken)
* Found gov/gprof builds don't enforce --disable-pie
* Fixed a minor compiler warning when stderr/ftrace back-end enabled

I'm sending this before confirming a clean run (which takes around 2
hours on the Travis infrastructure). However you can watch it's
progress at:

https://travis-ci.org/stsquad/qemu/builds/11694820

Given I found a couple of issues while doing this I think this is
useful alongside the existing buildbot efforts. It allows developers
to run simple smoke-tests without access to the buildbot
infrastructure (but of course needing github/travis access, free for
FLOSS projects). I can see further development possibilities in the
future, one example would be a tree that auto-generates branches with
testing results for each patch series as they come into the mailing
list.

Alex Bennée (3):
  .travis.yml: basic compile and check recipes
  .travis.yml: greatly expand the coverage + more builds
  block/stream.c: ensure copy always set

 .travis.yml| 55 +++
 block/stream.c |  2 ++
 2 files changed, 57 insertions(+)

[Qemu-devel] [PATCH 1/3] .travis.yml: basic compile and check recipes

2013-09-23 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

While QEMU already has various continuous integration set-ups in
buildbot and commercial Jenkins setups there is some value in supporting
travis-ci as well. It is well integrated into GitHub work flow and will
trigger on all branch pushes and pull requests. This makes it easier for
an individual to kick off smoke tests on a work-in-progress branch
before eventual submission of patches/pull requests upstream.

The build matrix is currently split by target architecture because a
full build of QEMU can take some time. This way you get quick feedback
for any obvious errors.
---
 .travis.yml | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..69f60c1
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,19 @@
+language: c
+env:
+  - TARGETS=alpha-softmmu,alpha-linux-user
+  - TARGETS=arm-softmmu,arm-linux-user
+  - TARGETS=cris-softmmu
+  - TARGETS=i386-softmmu,x86_64-softmmu
+  - TARGETS=lm32-softmmu
+  - TARGETS=m68k-softmmu 
+  - TARGETS=microblaze-softmmu,microblazeel-softmmu
+  - TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
+  - TARGETS=moxie-softmmu
+  - TARGETS=or32-softmmu,
+  - TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
+  - TARGETS=s390x-softmmu
+  - TARGETS=sh4-softmmu,sh4eb-softmmu
+  - TARGETS=sparc-softmmu,sparc64-softmmu
+  - TARGETS=unicore32-softmmu
+  - TARGETS=xtensa-softmmu,xtensaeb-softmmu
+script: ./configure --target-list=${TARGETS}  make  make check
-- 
1.8.4

[Qemu-devel] [PATCH 2/3] .travis.yml: greatly expand the coverage + more builds

2013-09-23 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

I've made the definitions more modular to allow for greater build
control in each part of the matrix. I've confined the additional stuff
to x86/x86_64 for convenience.
---
 .travis.yml | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 69f60c1..f311f84 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,5 +1,14 @@
 language: c
 env:
+  global:
+- TEST_CMD=make check
+- EXTRA_CONFIG=
+# Development packages, EXTRA_PKGS saved for additional builds
+- CORE_PKGS=libusb-1.0-0-dev libiscsi-dev librados-dev libncurses5-dev
+- NET_PKGS=libseccomp-dev libgnutls-dev libssh2-1-dev  
libspice-server-dev libspice-protocol-dev libnss3-dev
+- GUI_PKGS=libgtk-3-dev libvte-2.90-dev libsdl1.2-dev libpng12-dev 
libpixman-1-dev
+- EXTRA_PKGS=
+  matrix:
   - TARGETS=alpha-softmmu,alpha-linux-user
   - TARGETS=arm-softmmu,arm-linux-user
   - TARGETS=cris-softmmu
@@ -16,4 +25,31 @@ env:
   - TARGETS=sparc-softmmu,sparc64-softmmu
   - TARGETS=unicore32-softmmu
   - TARGETS=xtensa-softmmu,xtensaeb-softmmu
-script: ./configure --target-list=${TARGETS}  make  make check
+before_install:
+  - git submodule update --init --recursive
+  - sudo apt-get update -qq
+  - sudo apt-get install -qq ${CORE_PKGS} ${NET_PKGS} ${GUI_PKGS} ${EXTRA_PKGS}
+script: ./configure --target-list=${TARGETS} ${EXTRA_CONFIG}  make  
${TEST_CMD}
+matrix:
+  # We manually include a number of additional build for non-standard bits
+  include:
+# Debug related options
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-debug--enable-debug-tcg 
--enable-tcg-interpreter
+# Currently configure doesn't force --disable-pie
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-gprof --enable-gcov --disable-pie
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_PKGS=sparse
+   EXTRA_CONFIG=--enable-sparse
+# All the trace backends (apart from dtrace)
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=stderr
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=simple
+- env: TARGETS=i386-softmmu,x86_64-softmmu
+   EXTRA_CONFIG=--enable-trace-backend=ftrace
+# Currently broken on 12.04 due to mis-packaged liburcu and changed API, 
will be pulled.
+#- env: TARGETS=i386-softmmu,x86_64-softmmu
+#   EXTRA_PKGS=liblttng-ust-dev liburcu-dev
+#   EXTRA_CONFIG=--enable-trace-backend=ust
-- 
1.8.4

[Qemu-devel] [PATCH 3/3] block/stream.c: ensure copy always set

2013-09-23 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

This only showed up when compiling with
--enable-trace-backend=stderr|ftrace at which point the compiler
complains with the following:

block/stream.c: In function ‘stream_run’:
block/stream.c:141:22: error: ‘copy’ may be used uninitialized in this function 
[-Werror=uninitialized]

Not sure exactly why it needs these options but it does seem clear the
negative return case should be handled.
---
 block/stream.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/block/stream.c b/block/stream.c
index 078ce4a..3b9c198 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -136,6 +136,8 @@ wait:
 }
 
 copy = (ret == 1);
+} else {
+copy = false;
 }
 trace_stream_one_iteration(s, sector_num, n, ret);
 if (ret = 0  copy) {
-- 
1.8.4

[Qemu-devel] [PATCH v2 1/1] integrator: fix Linux boot failure by emulating dbg

2013-09-18 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

Commit 9b8c69243 broke the ability to boot the kernel as the value
returned by unassigned_mem_read returned non-zero and left the kernel
looping forever waiting for it to change (see integrator_led_set in
the kernel code).

Relying on a varying implementation detail is incorrect anyway so this
introduces a memory region to emulate the debug/led region on the
integrator board. It is currently a basic stub as I have no idea what the
behaviour of this region should be so for now it simply returns 0's as
the old unassigned_mem_read did.

Signed-off-by: Alex Bennée a...@bennee.com
---
 default-configs/arm-softmmu.mak |  1 +
 hw/arm/integratorcp.c   |  1 +
 hw/misc/Makefile.objs   |  1 +
 hw/misc/arm_intdbg.c| 90 +
 4 files changed, 93 insertions(+)
 create mode 100644 hw/misc/arm_intdbg.c

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index ac0815d..a5718d1 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -80,3 +80,4 @@ CONFIG_VERSATILE_PCI=y
 CONFIG_VERSATILE_I2C=y
 
 CONFIG_SDHCI=y
+CONFIG_INTEGRATOR_DBG=y
diff --git a/hw/arm/integratorcp.c b/hw/arm/integratorcp.c
index 2ef93ed..46dc615 100644
--- a/hw/arm/integratorcp.c
+++ b/hw/arm/integratorcp.c
@@ -508,6 +508,7 @@ static void integratorcp_init(QEMUMachineInitArgs *args)
 icp_control_init(0xcb00);
 sysbus_create_simple(pl050_keyboard, 0x1800, pic[3]);
 sysbus_create_simple(pl050_mouse, 0x1900, pic[4]);
+sysbus_create_simple(integrator_dbg, 0x1a00, 0);
 sysbus_create_varargs(pl181, 0x1c00, pic[23], pic[24], NULL);
 if (nd_table[0].used)
 smc91c111_init(nd_table[0], 0xc800, pic[27]);
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 2578e29..be284f3 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -10,6 +10,7 @@ obj-$(CONFIG_VMPORT) += vmport.o
 
 # ARM devices
 common-obj-$(CONFIG_PL310) += arm_l2x0.o
+common-obj-$(CONFIG_INTEGRATOR_DBG) += arm_intdbg.o
 
 # PKUnity SoC devices
 common-obj-$(CONFIG_PUV3) += puv3_pm.o
diff --git a/hw/misc/arm_intdbg.c b/hw/misc/arm_intdbg.c
new file mode 100644
index 000..b505d09
--- /dev/null
+++ b/hw/misc/arm_intdbg.c
@@ -0,0 +1,90 @@
+/*
+ * LED, Switch and Debug control registers for ARM Integrator Boards
+ *
+ * This currently is a stub for this functionality written with
+ * reference to what the Linux kernel looks at. Previously we relied
+ * on the behaviour of unassigned_mem_read() in the core.
+ *
+ * The real h/w is described at:
+ *  
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0159b/Babbfijf.html
+ *
+ * Written by Alex Bennée
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include hw/hw.h
+#include hw/sysbus.h
+#include exec/address-spaces.h
+
+#define TYPE_ARM_INTDBG integrator_dbg
+#define ARM_INTDBG(obj) \
+OBJECT_CHECK(ARMIntDbgState, (obj), TYPE_ARM_INTDBG)
+
+typedef struct {
+SysBusDevice parent_obj;
+MemoryRegion iomem;
+
+uint32_t alpha;
+uint32_t leds;
+uint32_t switches;
+} ARMIntDbgState;
+
+static uint64_t dbg_control_read(void *opaque, hwaddr offset,
+ unsigned size)
+{
+switch (offset  2) {
+case 0: /* ALPHA */
+case 1: /* LEDS */
+case 2: /* SWITCHES */
+qemu_log_mask(LOG_UNIMP, dbg_control_read: returning zero from 
%x:%d\n, (int)offset, size);
+return 0;
+default:
+qemu_log_mask(LOG_GUEST_ERROR, dbg_control_read: Bad offset %x\n, 
(int)offset);
+return 0;
+}
+}
+
+static void dbg_control_write(void *opaque, hwaddr offset,
+  uint64_t value, unsigned size)
+{
+switch (offset  2) {
+case 1: /* ALPHA */
+case 2: /* LEDS */
+case 3: /* SWITCHES */
+/* Nothing interesting implemented yet.  */
+qemu_log_mask(LOG_UNIMP, dbg_control_write: ignoring write of %lx to 
%x:%d\n, value, (int)offset, size);
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR, dbg_control_write: write of %lx to bad 
offset %x\n, value, (int)offset);
+}
+}
+
+static const MemoryRegionOps dbg_control_ops = {
+.read = dbg_control_read,
+.write = dbg_control_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void dbg_control_init(Object *obj)
+{
+SysBusDevice *sd = SYS_BUS_DEVICE(obj);
+ARMIntDbgState *s = ARM_INTDBG(obj);
+memory_region_init_io(s-iomem, NULL, dbg_control_ops, NULL, dbgleds, 
0x100);
+sysbus_init_mmio(sd, s-iomem);
+}
+
+static const TypeInfo arm_intdbg_info = {
+.name  = TYPE_ARM_INTDBG,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(ARMIntDbgState),
+.instance_init = dbg_control_init,
+};
+
+static void arm_intdbg_register_types(void)
+{
+

[Qemu-devel] [PATCH v2 1/1] integrator: fix Linux boot failure by emulating dbg

2013-09-18 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

Commit 9b8c69243 broke the ability to boot the kernel as the value
returned by unassigned_mem_read returned non-zero and left the kernel
looping forever waiting for it to change (see integrator_led_set in
the kernel code).

Relying on a varying implementation detail is incorrect anyway so this
introduces a memory region to emulate the debug/led region on the
integrator board. It is currently a basic stub as I have no idea what the
behaviour of this region should be so for now it simply returns 0's as
the old unassigned_mem_read did.

Signed-off-by: Alex Bennée a...@bennee.com
---
 default-configs/arm-softmmu.mak |  1 +
 hw/arm/integratorcp.c   |  1 +
 hw/misc/Makefile.objs   |  1 +
 hw/misc/arm_intdbg.c| 90 +
 4 files changed, 93 insertions(+)
 create mode 100644 hw/misc/arm_intdbg.c

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index ac0815d..a5718d1 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -80,3 +80,4 @@ CONFIG_VERSATILE_PCI=y
 CONFIG_VERSATILE_I2C=y
 
 CONFIG_SDHCI=y
+CONFIG_INTEGRATOR_DBG=y
diff --git a/hw/arm/integratorcp.c b/hw/arm/integratorcp.c
index 2ef93ed..46dc615 100644
--- a/hw/arm/integratorcp.c
+++ b/hw/arm/integratorcp.c
@@ -508,6 +508,7 @@ static void integratorcp_init(QEMUMachineInitArgs *args)
 icp_control_init(0xcb00);
 sysbus_create_simple(pl050_keyboard, 0x1800, pic[3]);
 sysbus_create_simple(pl050_mouse, 0x1900, pic[4]);
+sysbus_create_simple(integrator_dbg, 0x1a00, 0);
 sysbus_create_varargs(pl181, 0x1c00, pic[23], pic[24], NULL);
 if (nd_table[0].used)
 smc91c111_init(nd_table[0], 0xc800, pic[27]);
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 2578e29..be284f3 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -10,6 +10,7 @@ obj-$(CONFIG_VMPORT) += vmport.o
 
 # ARM devices
 common-obj-$(CONFIG_PL310) += arm_l2x0.o
+common-obj-$(CONFIG_INTEGRATOR_DBG) += arm_intdbg.o
 
 # PKUnity SoC devices
 common-obj-$(CONFIG_PUV3) += puv3_pm.o
diff --git a/hw/misc/arm_intdbg.c b/hw/misc/arm_intdbg.c
new file mode 100644
index 000..b505d09
--- /dev/null
+++ b/hw/misc/arm_intdbg.c
@@ -0,0 +1,90 @@
+/*
+ * LED, Switch and Debug control registers for ARM Integrator Boards
+ *
+ * This currently is a stub for this functionality written with
+ * reference to what the Linux kernel looks at. Previously we relied
+ * on the behaviour of unassigned_mem_read() in the core.
+ *
+ * The real h/w is described at:
+ *  
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0159b/Babbfijf.html
+ *
+ * Written by Alex Bennée
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include hw/hw.h
+#include hw/sysbus.h
+#include exec/address-spaces.h
+
+#define TYPE_ARM_INTDBG integrator_dbg
+#define ARM_INTDBG(obj) \
+OBJECT_CHECK(ARMIntDbgState, (obj), TYPE_ARM_INTDBG)
+
+typedef struct {
+SysBusDevice parent_obj;
+MemoryRegion iomem;
+
+uint32_t alpha;
+uint32_t leds;
+uint32_t switches;
+} ARMIntDbgState;
+
+static uint64_t dbg_control_read(void *opaque, hwaddr offset,
+ unsigned size)
+{
+switch (offset  2) {
+case 0: /* ALPHA */
+case 1: /* LEDS */
+case 2: /* SWITCHES */
+qemu_log_mask(LOG_UNIMP, dbg_control_read: returning zero from 
%x:%d\n, (int)offset, size);
+return 0;
+default:
+qemu_log_mask(LOG_GUEST_ERROR, dbg_control_read: Bad offset %x\n, 
(int)offset);
+return 0;
+}
+}
+
+static void dbg_control_write(void *opaque, hwaddr offset,
+  uint64_t value, unsigned size)
+{
+switch (offset  2) {
+case 1: /* ALPHA */
+case 2: /* LEDS */
+case 3: /* SWITCHES */
+/* Nothing interesting implemented yet.  */
+qemu_log_mask(LOG_UNIMP, dbg_control_write: ignoring write of %lx to 
%x:%d\n, value, (int)offset, size);
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR, dbg_control_write: write of %lx to bad 
offset %x\n, value, (int)offset);
+}
+}
+
+static const MemoryRegionOps dbg_control_ops = {
+.read = dbg_control_read,
+.write = dbg_control_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void dbg_control_init(Object *obj)
+{
+SysBusDevice *sd = SYS_BUS_DEVICE(obj);
+ARMIntDbgState *s = ARM_INTDBG(obj);
+memory_region_init_io(s-iomem, NULL, dbg_control_ops, NULL, dbgleds, 
0x100);
+sysbus_init_mmio(sd, s-iomem);
+}
+
+static const TypeInfo arm_intdbg_info = {
+.name  = TYPE_ARM_INTDBG,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(ARMIntDbgState),
+.instance_init = dbg_control_init,
+};
+
+static void arm_intdbg_register_types(void)
+{
+

[Qemu-devel] [PATCH v2 0/0] integrator: fix Linux boot failure by emulating dbg

2013-09-18 Thread alex . bennee 
Hi,

I mistakenly appended this to the previous patch revision. I'm now
sending for further review.

Since v1:
  - Updated with Peter Maydell's review comments.

--
Alex Bennée

[Qemu-devel] [PATCH v2 1/1] integrator: fix Linux boot failure by emulating dbg

2013-09-16 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

Commit 9b8c69243 broke the ability to boot the kernel as the value
returned by unassigned_mem_read returned non-zero and left the kernel
looping forever waiting for it to change (see integrator_led_set in
the kernel code).

Relying on a varying implementation detail is incorrect anyway so this
introduces a memory region to emulate the debug/led region on the
integrator board. It is currently a basic stub as I have no idea what the
behaviour of this region should be so for now it simply returns 0's as
the old unassigned_mem_read did.

Signed-off-by: Alex Bennée a...@bennee.com
---
 default-configs/arm-softmmu.mak |  1 +
 hw/arm/integratorcp.c   |  1 +
 hw/misc/Makefile.objs   |  1 +
 hw/misc/arm_intdbg.c| 90 +
 4 files changed, 93 insertions(+)
 create mode 100644 hw/misc/arm_intdbg.c

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index ac0815d..a5718d1 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -80,3 +80,4 @@ CONFIG_VERSATILE_PCI=y
 CONFIG_VERSATILE_I2C=y
 
 CONFIG_SDHCI=y
+CONFIG_INTEGRATOR_DBG=y
diff --git a/hw/arm/integratorcp.c b/hw/arm/integratorcp.c
index 2ef93ed..46dc615 100644
--- a/hw/arm/integratorcp.c
+++ b/hw/arm/integratorcp.c
@@ -508,6 +508,7 @@ static void integratorcp_init(QEMUMachineInitArgs *args)
 icp_control_init(0xcb00);
 sysbus_create_simple(pl050_keyboard, 0x1800, pic[3]);
 sysbus_create_simple(pl050_mouse, 0x1900, pic[4]);
+sysbus_create_simple(integrator_dbg, 0x1a00, 0);
 sysbus_create_varargs(pl181, 0x1c00, pic[23], pic[24], NULL);
 if (nd_table[0].used)
 smc91c111_init(nd_table[0], 0xc800, pic[27]);
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 2578e29..be284f3 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -10,6 +10,7 @@ obj-$(CONFIG_VMPORT) += vmport.o
 
 # ARM devices
 common-obj-$(CONFIG_PL310) += arm_l2x0.o
+common-obj-$(CONFIG_INTEGRATOR_DBG) += arm_intdbg.o
 
 # PKUnity SoC devices
 common-obj-$(CONFIG_PUV3) += puv3_pm.o
diff --git a/hw/misc/arm_intdbg.c b/hw/misc/arm_intdbg.c
new file mode 100644
index 000..b505d09
--- /dev/null
+++ b/hw/misc/arm_intdbg.c
@@ -0,0 +1,90 @@
+/*
+ * LED, Switch and Debug control registers for ARM Integrator Boards
+ *
+ * This currently is a stub for this functionality written with
+ * reference to what the Linux kernel looks at. Previously we relied
+ * on the behaviour of unassigned_mem_read() in the core.
+ *
+ * The real h/w is described at:
+ *  
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0159b/Babbfijf.html
+ *
+ * Written by Alex Bennée
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include hw/hw.h
+#include hw/sysbus.h
+#include exec/address-spaces.h
+
+#define TYPE_ARM_INTDBG integrator_dbg
+#define ARM_INTDBG(obj) \
+OBJECT_CHECK(ARMIntDbgState, (obj), TYPE_ARM_INTDBG)
+
+typedef struct {
+SysBusDevice parent_obj;
+MemoryRegion iomem;
+
+uint32_t alpha;
+uint32_t leds;
+uint32_t switches;
+} ARMIntDbgState;
+
+static uint64_t dbg_control_read(void *opaque, hwaddr offset,
+ unsigned size)
+{
+switch (offset  2) {
+case 0: /* ALPHA */
+case 1: /* LEDS */
+case 2: /* SWITCHES */
+qemu_log_mask(LOG_UNIMP, dbg_control_read: returning zero from 
%x:%d\n, (int)offset, size);
+return 0;
+default:
+qemu_log_mask(LOG_GUEST_ERROR, dbg_control_read: Bad offset %x\n, 
(int)offset);
+return 0;
+}
+}
+
+static void dbg_control_write(void *opaque, hwaddr offset,
+  uint64_t value, unsigned size)
+{
+switch (offset  2) {
+case 1: /* ALPHA */
+case 2: /* LEDS */
+case 3: /* SWITCHES */
+/* Nothing interesting implemented yet.  */
+qemu_log_mask(LOG_UNIMP, dbg_control_write: ignoring write of %lx to 
%x:%d\n, value, (int)offset, size);
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR, dbg_control_write: write of %lx to bad 
offset %x\n, value, (int)offset);
+}
+}
+
+static const MemoryRegionOps dbg_control_ops = {
+.read = dbg_control_read,
+.write = dbg_control_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void dbg_control_init(Object *obj)
+{
+SysBusDevice *sd = SYS_BUS_DEVICE(obj);
+ARMIntDbgState *s = ARM_INTDBG(obj);
+memory_region_init_io(s-iomem, NULL, dbg_control_ops, NULL, dbgleds, 
0x100);
+sysbus_init_mmio(sd, s-iomem);
+}
+
+static const TypeInfo arm_intdbg_info = {
+.name  = TYPE_ARM_INTDBG,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(ARMIntDbgState),
+.instance_init = dbg_control_init,
+};
+
+static void arm_intdbg_register_types(void)
+{
+

[Qemu-devel] [PATCH v2 0/0] integrator: fix Linux boot failure by emulating dbg

2013-09-16 Thread alex . bennee 
Hi,

I've applied the review comments from Peter.

Alex.

[Qemu-devel] [PATCH] integrator: fix Linux boot failure by emulating dbg

2013-09-13 Thread alex . bennee 
From: Alex Benn??e a...@bennee.com

Commit 9b8c69243 broke the ability to boot the kernel as the value
returned by unassigned_mem_read returned non-zero and left the kernel
looping forever waiting for it to change (see integrator_led_set in
the kernel code).

Relying on a varying implementation detail is incorrect anyway so this
introduces a memory region to emulate the debug/led region on the
integrator board. It is currently a basic stub as I have no idea what the
behaviour of this region should be so for now it simply returns 0's as
the old unassigned_mem_read did.
---
 hw/arm/integratorcp.c |  2 ++
 hw/misc/Makefile.objs |  1 +
 hw/misc/arm_intdbg.c  | 90 +++
 3 files changed, 93 insertions(+)
 create mode 100644 hw/misc/arm_intdbg.c

diff --git a/hw/arm/integratorcp.c b/hw/arm/integratorcp.c
index 2ef93ed..e5d07c4 100644
--- a/hw/arm/integratorcp.c
+++ b/hw/arm/integratorcp.c
@@ -446,6 +446,7 @@ static void icp_control_init(hwaddr base)
 }
 
 
+
 /* Board init.  */
 
 static struct arm_boot_info integrator_binfo = {
@@ -508,6 +509,7 @@ static void integratorcp_init(QEMUMachineInitArgs *args)
 icp_control_init(0xcb00);
 sysbus_create_simple(pl050_keyboard, 0x1800, pic[3]);
 sysbus_create_simple(pl050_mouse, 0x1900, pic[4]);
+sysbus_create_simple(integrator_dbg, 0x1a00, 0);
 sysbus_create_varargs(pl181, 0x1c00, pic[23], pic[24], NULL);
 if (nd_table[0].used)
 smc91c111_init(nd_table[0], 0xc800, pic[27]);
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 2578e29..e2c84a3 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -22,6 +22,7 @@ obj-$(CONFIG_LINUX) += vfio.o
 endif
 
 obj-$(CONFIG_REALVIEW) += arm_sysctl.o
+obj-y += arm_intdbg.o
 obj-$(CONFIG_A9SCU) += a9scu.o
 obj-$(CONFIG_NSERIES) += cbus.o
 obj-$(CONFIG_ECCMEMCTL) += eccmemctl.o
diff --git a/hw/misc/arm_intdbg.c b/hw/misc/arm_intdbg.c
new file mode 100644
index 000..1f21447
--- /dev/null
+++ b/hw/misc/arm_intdbg.c
@@ -0,0 +1,90 @@
+/*
+ * LED, Switch and Debug control registers for ARM Integrator Boards
+ *
+ * This currently is a stub for this functionality written with
+ * reference to what the Linux kernel looks at. Previously we relied
+ * on the behaviour of unassigned_mem_read() in the core.
+ *
+ * Written by Alex Benn??e
+ *
+ * This code is licensed under the GPL.
+ */
+
+#include hw/hw.h
+#include hw/sysbus.h
+#include exec/address-spaces.h
+
+#define TYPE_ARM_INTDBG integrator_dbg
+#define ARM_INTDBG(obj) \
+OBJECT_CHECK(arm_intdbg_state, (obj), TYPE_ARM_INTDBG)
+
+typedef struct {
+SysBusDevice parent_obj;
+MemoryRegion iomem;
+
+uint32_t alpha;
+uint32_t leds;
+uint32_t switches;
+} arm_intdbg_state;
+
+static uint64_t dbg_control_read(void *opaque, hwaddr offset,
+ unsigned size)
+{
+switch (offset  2) {
+case 0: /* ALPHA */
+return 0;
+case 1: /* LEDS */
+return 0;
+case 2: /* SWITCHES */
+return 0;
+default:
+hw_error(dbg_control_read: Bad offset %x\n, (int)offset);
+return 0;
+}
+}
+
+static void dbg_control_write(void *opaque, hwaddr offset,
+  uint64_t value, unsigned size)
+{
+switch (offset  2) {
+case 1: /* ALPHA */
+case 2: /* LEDS */
+case 3: /* SWITCHES */
+/* Nothing interesting implemented yet.  */
+break;
+default:
+hw_error(dbg_control_write: Bad offset %x\n, (int)offset);
+}
+}
+
+static const MemoryRegionOps dbg_control_ops = {
+.read = dbg_control_read,
+.write = dbg_control_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void dbg_control_init(Object *obj)
+{
+SysBusDevice *sd = SYS_BUS_DEVICE(obj);
+arm_intdbg_state *s = ARM_INTDBG(obj);
+memory_region_init_io(s-iomem, NULL, dbg_control_ops, NULL, dbgleds, 
0x1000);
+sysbus_init_mmio(sd, s-iomem);
+}
+
+/*
+  Hardware boilerplate
+*/
+
+static const TypeInfo arm_intdbg_info = {
+.name  = TYPE_ARM_INTDBG,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(arm_intdbg_state),
+.instance_init = dbg_control_init,
+};
+
+static void arm_intdbg_register_types(void)
+{
+type_register_static(arm_intdbg_info);
+}
+
+type_init(arm_intdbg_register_types)
-- 
1.8.4

[Qemu-devel] [PATCH] .travis.yml: basic compile and check recipes

2013-09-13 Thread alex . bennee 
From: Alex Bennée a...@bennee.com

While QEMU already has various continuous integration set-ups in
buildbot and commercial Jenkins setups there is some value in supporting
travis-ci as well. It is well integrated into GitHub work flow and will
trigger on all branch pushes and pull requests. This makes it easier for
an individual to kick off smoke tests on a work-in-progress branch
before eventual submission of patches/pull requests upstream.

The build matrix is currently split by target architecture because a
full build of QEMU can take some time. This way you get quick feedback
for any obvious errors.
---
 .travis.yml | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..69f60c1
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,19 @@
+language: c
+env:
+  - TARGETS=alpha-softmmu,alpha-linux-user
+  - TARGETS=arm-softmmu,arm-linux-user
+  - TARGETS=cris-softmmu
+  - TARGETS=i386-softmmu,x86_64-softmmu
+  - TARGETS=lm32-softmmu
+  - TARGETS=m68k-softmmu 
+  - TARGETS=microblaze-softmmu,microblazeel-softmmu
+  - TARGETS=mips-softmmu,mips64-softmmu,mips64el-softmmu,mipsel-softmmu
+  - TARGETS=moxie-softmmu
+  - TARGETS=or32-softmmu,
+  - TARGETS=ppc-softmmu,ppc64-softmmu,ppcemb-softmmu
+  - TARGETS=s390x-softmmu
+  - TARGETS=sh4-softmmu,sh4eb-softmmu
+  - TARGETS=sparc-softmmu,sparc64-softmmu
+  - TARGETS=unicore32-softmmu
+  - TARGETS=xtensa-softmmu,xtensaeb-softmmu
+script: ./configure --target-list=${TARGETS}  make  make check
-- 
1.8.4

subscribe

2013-09-04 Thread Alex Bennee 

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[Bug 1218819] [NEW] libfdt-dev is broken for current LTS release

2013-08-30 Thread Alex Bennee 
Public bug reported:

Currently attempts to use libfdt-dev will fail as the packaging doesn't
include the libfdt_env.h header required by the others. One place this
breaks for example is trying to compile the current QEMU using system
libraries. This has already been fixed upstream so the fix should be
just to import the latest 1.3.0-3 of the device-tree-compiler package.

** Affects: device-tree-compiler (Ubuntu)
 Importance: Undecided
 Status: New

** Bug watch added: Debian Bug tracker #706137
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706137

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1218819

Title:
  libfdt-dev is broken for current LTS release

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/device-tree-compiler/+bug/1218819/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1218819] Re: libfdt-dev is broken for current LTS release

2013-08-30 Thread Alex Bennee 
This is the upstream bug-report: http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=706137

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1218819

Title:
  libfdt-dev is broken for current LTS release

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/device-tree-compiler/+bug/1218819/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1218819] Re: libfdt-dev is broken for current LTS release

2013-08-30 Thread Alex Bennee 
I can confirm that after hand-building Debian's device-tree-
compiler_1.3.0-4 packages and installing them I could successfully build
something using libfdt-dev (qemu).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1218819

Title:
  libfdt-dev is broken for current LTS release

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/device-tree-compiler/+bug/1218819/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Wireshark-dev] ATM over Ethernet

2012-11-05 Thread Alex Bennee 
Hi,

We use a fairly simple ATM over Ethernet encapsulation for linking old
ATM based circuits with modern Ethernet based hardware. I was able to
enable the packet-atm.c to decde these frames very easily (see
attached) but I was looking for pointers for the next bit.

Currently I can't see a way to specify treating the rest of the frame
as multiple frames. Do I need to extend the ATM dissector to call
itself if the remaining frame is larger than 53 bytes?

Also how is the AAL encoding determined? Should I just register the
handlers for the multiple AAL types and let the user decide?

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk


0001-Allow-ATMoE-encapsulated-ATM-to-be-decoded-by-ATM-di.patch
Description: Binary data
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

[Bug 624877] Re: INFO: task dpkg:23317 blocked for more than 120 seconds.

2012-09-18 Thread Alex Bennee 
So I have verified that the proposed dpkg no longer hangs. I used the
following script to generate heavy load on the system:

#!/bin/bash
#
# Generate IO load
echo starting load
#dd if=/dev/zero of=zero 
sleep 1s
dd if=/dev/urandom of=urandom 
sleep 1s
dd if=/dev/sda1 of=sda1_backup1 
sleep 1s
dd if=/dev/sda1 of=sda1_backup2 
sleep 1s
dd if=/dev/sda1 of=sda1_backup3 
sleep 1s
dd if=/dev/sda1 of=sda1_backup4 
echo All load running
sleep 10m
echo 10 minutes passed
sleep 10m
echo Finishing
killall dd

And then run a couple of apt-get dist-upgrades with some large packages.
Although dpkg ran really slowly (due to the load) I was unable to
trigger the kernel D state hang.

** Tags removed: verification-needed
** Tags added: verification-done

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/624877

Title:
  INFO: task dpkg:23317 blocked for more than 120 seconds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/624877/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 624877] Re: INFO: task dpkg:23317 blocked for more than 120 seconds.

2012-09-14 Thread Alex Bennee 
Thanks to Ted for clearly elucidating the two competing issues. For the
time being we can't move from 10.04 (whole OS upgrades tend to be
unpopular with customers for point releases). However as the kernel lock
is always triggered by dpkg I'm hoping that just fixing dpkg will be
enough. I assume if you make the system quiescent enough but shutting
down all I/O the kernel will eventually un-wedge itself and allow a
sync() based dpkg to complete?

Anyway I've tested Michael Jeanson's patch and I can confirm that even
under a highly I/O loaded system dpkg now does work it's way (slowly)
through a bunch of packages and eventually completes. I'm fairly happy
to ship it in our products repositories although of course look forward
to upstream finally adopting the fix.

Are there any regression tests I can run against dpkg to make sure
nothing else is broken?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/624877

Title:
  INFO: task dpkg:23317 blocked for more than 120 seconds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/624877/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 624877] Re: INFO: task dpkg:23317 blocked for more than 120 seconds.

2012-09-13 Thread Alex Bennee 
Surely the fix required is for the kernel? While dpkg might be good at
triggering the bug it may not be the only thing that can hang the kernel
requiring a hard reset.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/624877

Title:
  INFO: task dpkg:23317 blocked for more than 120 seconds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/624877/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 624877] Re: INFO: task dpkg:23317 blocked for more than 120 seconds.

2012-09-13 Thread Alex Bennee 
The behaviour we are seeing is dpkg hangs and never returns. As dpkg is
left in the D state and is un-killable the only recourse is to hard
reset the box (power-cycle) it. However it might be due to file-system
load it can never achieve the file-system sync. I'm currently trying to
come up with a reliable reproduction that doesn't involve hosing our
customer boxes

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/624877

Title:
  INFO: task dpkg:23317 blocked for more than 120 seconds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/624877/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 624877] Re: INFO: task dpkg:23317 blocked for more than 120 seconds.

2012-08-28 Thread Alex Bennee 
I'm confused as to when this fix was released.  I can't see any
reference to this bug in the changelogs of either dpkg or the linux-
image. I'm seeing on customer 10.04LTS machines running the latest
packages which makes me think the bug is still there.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/624877

Title:
  INFO: task dpkg:23317 blocked for more than 120 seconds.

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/624877/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 979758] Re: package fails to configure on failing to find /etc/init.d/nis

2012-04-12 Thread Alex Bennee 
I suspect the invoke-rc.d line needs to be wrapped in the -e part of the
of the check?

The current preinst code looks like:

# Manually remove the nis init script, which has to be split into per-daemon
# upstart jobs
if dpkg --compare-versions $2 lt-nl 3.17-32ubuntu1.1
then
# since this isn't stopped on upgrade, we have to stop it now
# so we don't leave orphaned processes running
invoke-rc.d nis stop
if [ -e /etc/init.d/nis ]  [ ! -L /etc/init.d/nis ]; then
if [ `md5sum \/etc/init.d/nis\ | sed -e \s/ .*//\` != \
 `dpkg-query -W -f='${Conffiles}' nis | sed -n -e \' 
/etc/init.d/nis '{s/ obsolete$//;s/.* //p}\` ]
then
echo Obsolete conffile /etc/init.d/nis has been 
modified by you, renaming to .dpkg-bak
mv -f /etc/init.d/nis /etc/init.d/nis.dpkg-bak
else
rm -f /etc/init.d/nis
fi
fi
update-rc.d nis remove
fi

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nis in Ubuntu.
https://bugs.launchpad.net/bugs/979758

Title:
  package fails to configure on failing to find /etc/init.d/nis

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nis/+bug/979758/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 979758] [NEW] package fails to configure on failing to find /etc/init.d/nis

2012-04-12 Thread Alex Bennee 
Public bug reported:

On upgrading to Precise I find that apt cannot complete due to a
--unpack failure running the pre-installation script.

dpkg --unpack /var/cache/apt/archives/nis_3.17-32ubuntu4_amd64.deb
(Reading database ... 313937 files and directories currently installed.)
Preparing to replace nis 3.17-32ubuntu1.2 (using 
.../nis_3.17-32ubuntu4_amd64.deb) ...
invoke-rc.d: unknown initscript, /etc/init.d/nis not found.
dpkg: error processing /var/cache/apt/archives/nis_3.17-32ubuntu4_amd64.deb 
(--unpack):
 subprocess new pre-installation script returned error exit status 100
ypbind stop/waiting
ypbind start/running, process 3261
ypserv stop/pre-start, process 3290
Errors were encountered while processing:
 /var/cache/apt/archives/nis_3.17-32ubuntu4_amd64.deb

Additional info:

11:36 root@sloy/x86_64 [sources.list.d] lsb_release -rd
Description:Ubuntu precise (development branch)
Release:12.04

11:36 root@sloy/x86_64 [sources.list.d] apt-cache policy nis
nis:
  Installed: 3.17-32ubuntu1.2
  Candidate: 3.17-32ubuntu4
  Version table:
 3.17-32ubuntu4 0
500 http://gb.archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages
 *** 3.17-32ubuntu1.2 0
100 /var/lib/dpkg/status

** Affects: nis (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/979758

Title:
  package fails to configure on failing to find /etc/init.d/nis

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nis/+bug/979758/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 979758] Re: package fails to configure on failing to find /etc/init.d/nis

2012-04-12 Thread Alex Bennee 
I suspect the invoke-rc.d line needs to be wrapped in the -e part of the
of the check?

The current preinst code looks like:

# Manually remove the nis init script, which has to be split into per-daemon
# upstart jobs
if dpkg --compare-versions $2 lt-nl 3.17-32ubuntu1.1
then
# since this isn't stopped on upgrade, we have to stop it now
# so we don't leave orphaned processes running
invoke-rc.d nis stop
if [ -e /etc/init.d/nis ]  [ ! -L /etc/init.d/nis ]; then
if [ `md5sum \/etc/init.d/nis\ | sed -e \s/ .*//\` != \
 `dpkg-query -W -f='${Conffiles}' nis | sed -n -e \' 
/etc/init.d/nis '{s/ obsolete$//;s/.* //p}\` ]
then
echo Obsolete conffile /etc/init.d/nis has been 
modified by you, renaming to .dpkg-bak
mv -f /etc/init.d/nis /etc/init.d/nis.dpkg-bak
else
rm -f /etc/init.d/nis
fi
fi
update-rc.d nis remove
fi

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/979758

Title:
  package fails to configure on failing to find /etc/init.d/nis

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nis/+bug/979758/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Desktop-packages] [Bug 930330] Re: gnome-keyring-daemon leaks memory badly

2012-02-13 Thread Alex Bennee 
Following a weekend of my work machine idling and doing nothing I can
now report gnome-keyring-daemon is taking up 8.7% of my  memory:

983M (VIRT) 677M (RES) 8.7% MEM

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

Status in “gnome-keyring” package in Ubuntu:
  New

Bug description:
  There seems to be a persistent leak in gnome-keyring-daemon. Several
  times I've come into work to find a very sluggish machine swapping
  applications back in with the daemon consuming 45% of my system memory
  (according to htop on an 8GB machine). If there is any debugging tips
  to be offered on how to run the daemon outside of gnome-shell please
  let me know and I can valgrind it for you.

  Currently it's taking up a modest 510M of VIRT (238M RES), I expect this to 
be much more when I come back into the office on Monday.
  --- 
  ApportVersion: 1.23-0ubuntu4
  Architecture: amd64
  DistroRelease: Ubuntu 11.10
  InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
  Package: gnome-keyring 3.2.2-0ubuntu0.1
  PackageArchitecture: amd64
  ProcEnviron:
   SHELL=/bin/bash
   PATH=(custom, user)
   LANG=en_GB.UTF-8
   LANGUAGE=en_GB.UTF-8
   LC_CTYPE=en_GB.UTF-8
  ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
  Tags:  oneiric
  Uname: Linux 3.0.0-16-generic x86_64
  UpgradeStatus: Upgraded to oneiric on 2011-11-04 (98 days ago)
  UserGroups: adm adm admin admin cdrom cdrom dialout dialout libvirtd libvirtd 
lpadmin lpadmin plugdev plugdev rrdsock rrdsock sambashare sambashare sudo sudo 
trac

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 930330] Re: gnome-keyring-daemon leaks memory badly

2012-02-13 Thread Alex Bennee 
Apologies  - this package is part of the Gnome 3 PPA. According to
#179873 I can't assign this bug to a PPA so I'm unsure what to do. Will
contact the PPA manager directly.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

Status in “gnome-keyring” package in Ubuntu:
  New

Bug description:
  There seems to be a persistent leak in gnome-keyring-daemon. Several
  times I've come into work to find a very sluggish machine swapping
  applications back in with the daemon consuming 45% of my system memory
  (according to htop on an 8GB machine). If there is any debugging tips
  to be offered on how to run the daemon outside of gnome-shell please
  let me know and I can valgrind it for you.

  Currently it's taking up a modest 510M of VIRT (238M RES), I expect this to 
be much more when I come back into the office on Monday.
  --- 
  ApportVersion: 1.23-0ubuntu4
  Architecture: amd64
  DistroRelease: Ubuntu 11.10
  InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
  Package: gnome-keyring 3.2.2-0ubuntu0.1
  PackageArchitecture: amd64
  ProcEnviron:
   SHELL=/bin/bash
   PATH=(custom, user)
   LANG=en_GB.UTF-8
   LANGUAGE=en_GB.UTF-8
   LC_CTYPE=en_GB.UTF-8
  ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
  Tags:  oneiric
  Uname: Linux 3.0.0-16-generic x86_64
  UpgradeStatus: Upgraded to oneiric on 2011-11-04 (98 days ago)
  UserGroups: adm adm admin admin cdrom cdrom dialout dialout libvirtd libvirtd 
lpadmin lpadmin plugdev plugdev rrdsock rrdsock sambashare sambashare sudo sudo 
trac

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Bug 930330] Re: gnome-keyring-daemon leaks memory badly

2012-02-13 Thread Alex Bennee 
Following a weekend of my work machine idling and doing nothing I can
now report gnome-keyring-daemon is taking up 8.7% of my  memory:

983M (VIRT) 677M (RES) 8.7% MEM

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Bug 930330] Re: gnome-keyring-daemon leaks memory badly

2012-02-13 Thread Alex Bennee 
Apologies  - this package is part of the Gnome 3 PPA. According to
#179873 I can't assign this bug to a PPA so I'm unsure what to do. Will
contact the PPA manager directly.

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Bug 930330] Re: gnome-keyring-daemon leaks memory badly

2012-02-13 Thread Alex Bennee 
Following a weekend of my work machine idling and doing nothing I can
now report gnome-keyring-daemon is taking up 8.7% of my  memory:

983M (VIRT) 677M (RES) 8.7% MEM

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 930330] Re: gnome-keyring-daemon leaks memory badly

2012-02-13 Thread Alex Bennee 
Apologies  - this package is part of the Gnome 3 PPA. According to
#179873 I can't assign this bug to a PPA so I'm unsure what to do. Will
contact the PPA manager directly.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Desktop-packages] [Bug 930330] [NEW] gnome-keyring-daemon leaks memory badly

2012-02-10 Thread Alex Bennee 
Public bug reported:

There seems to be a persistent leak in gnome-keyring-daemon. Several
times I've come into work to find a very sluggish machine swapping
applications back in with the daemon consuming 45% of my system memory
(according to htop on an 8GB machine). If there is any debugging tips to
be offered on how to run the daemon outside of gnome-shell please let me
know and I can valgrind it for you.

Currently it's taking up a modest 510M of VIRT (238M RES), I expect this to be 
much more when I come back into the office on Monday.
--- 
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
DistroRelease: Ubuntu 11.10
InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
Package: gnome-keyring 3.2.2-0ubuntu0.1
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 LANGUAGE=en_GB.UTF-8
 LC_CTYPE=en_GB.UTF-8
ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
Tags:  oneiric
Uname: Linux 3.0.0-16-generic x86_64
UpgradeStatus: Upgraded to oneiric on 2011-11-04 (98 days ago)
UserGroups: adm adm admin admin cdrom cdrom dialout dialout libvirtd libvirtd 
lpadmin lpadmin plugdev plugdev rrdsock rrdsock sambashare sambashare sudo sudo 
trac

** Affects: gnome-keyring (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: apport-collected oneiric

** Tags added: apport-collected oneiric

** Description changed:

  There seems to be a persistent leak in gnome-keyring-daemon. Several
  times I've come into work to find a very sluggish machine swapping
  applications back in with the daemon consuming 45% of my system memory
  (according to htop on an 8GB machine). If there is any debugging tips to
  be offered on how to run the daemon outside of gnome-shell please let me
  know and I can valgrind it for you.
  
- Currently it's taking up a modest 510M of VIRT (238M RES), I expect this
- to be much more when I come back into the office on Monday.
+ Currently it's taking up a modest 510M of VIRT (238M RES), I expect this to 
be much more when I come back into the office on Monday.
+ --- 
+ ApportVersion: 1.23-0ubuntu4
+ Architecture: amd64
+ DistroRelease: Ubuntu 11.10
+ InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
+ Package: gnome-keyring 3.2.2-0ubuntu0.1
+ PackageArchitecture: amd64
+ ProcEnviron:
+  SHELL=/bin/bash
+  PATH=(custom, user)
+  LANG=en_GB.UTF-8
+  LANGUAGE=en_GB.UTF-8
+  LC_CTYPE=en_GB.UTF-8
+ ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
+ Tags:  oneiric
+ Uname: Linux 3.0.0-16-generic x86_64
+ UpgradeStatus: Upgraded to oneiric on 2011-11-04 (98 days ago)
+ UserGroups: adm adm admin admin cdrom cdrom dialout dialout libvirtd libvirtd 
lpadmin lpadmin plugdev plugdev rrdsock rrdsock sambashare sambashare sudo sudo 
trac

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

Status in “gnome-keyring” package in Ubuntu:
  New

Bug description:
  There seems to be a persistent leak in gnome-keyring-daemon. Several
  times I've come into work to find a very sluggish machine swapping
  applications back in with the daemon consuming 45% of my system memory
  (according to htop on an 8GB machine). If there is any debugging tips
  to be offered on how to run the daemon outside of gnome-shell please
  let me know and I can valgrind it for you.

  Currently it's taking up a modest 510M of VIRT (238M RES), I expect this to 
be much more when I come back into the office on Monday.
  --- 
  ApportVersion: 1.23-0ubuntu4
  Architecture: amd64
  DistroRelease: Ubuntu 11.10
  InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
  Package: gnome-keyring 3.2.2-0ubuntu0.1
  PackageArchitecture: amd64
  ProcEnviron:
   SHELL=/bin/bash
   PATH=(custom, user)
   LANG=en_GB.UTF-8
   LANGUAGE=en_GB.UTF-8
   LC_CTYPE=en_GB.UTF-8
  ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
  Tags:  oneiric
  Uname: Linux 3.0.0-16-generic x86_64
  UpgradeStatus: Upgraded to oneiric on 2011-11-04 (98 days ago)
  UserGroups: adm adm admin admin cdrom cdrom dialout dialout libvirtd libvirtd 
lpadmin lpadmin plugdev plugdev rrdsock rrdsock sambashare sambashare sudo sudo 
trac

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 930330] Dependencies.txt

2012-02-10 Thread Alex Bennee 
apport information

** Attachment added: Dependencies.txt
   
https://bugs.launchpad.net/bugs/930330/+attachment/2730042/+files/Dependencies.txt

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

Status in “gnome-keyring” package in Ubuntu:
  New

Bug description:
  There seems to be a persistent leak in gnome-keyring-daemon. Several
  times I've come into work to find a very sluggish machine swapping
  applications back in with the daemon consuming 45% of my system memory
  (according to htop on an 8GB machine). If there is any debugging tips
  to be offered on how to run the daemon outside of gnome-shell please
  let me know and I can valgrind it for you.

  Currently it's taking up a modest 510M of VIRT (238M RES), I expect this to 
be much more when I come back into the office on Monday.
  --- 
  ApportVersion: 1.23-0ubuntu4
  Architecture: amd64
  DistroRelease: Ubuntu 11.10
  InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
  Package: gnome-keyring 3.2.2-0ubuntu0.1
  PackageArchitecture: amd64
  ProcEnviron:
   SHELL=/bin/bash
   PATH=(custom, user)
   LANG=en_GB.UTF-8
   LANGUAGE=en_GB.UTF-8
   LC_CTYPE=en_GB.UTF-8
  ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
  Tags:  oneiric
  Uname: Linux 3.0.0-16-generic x86_64
  UpgradeStatus: Upgraded to oneiric on 2011-11-04 (98 days ago)
  UserGroups: adm adm admin admin cdrom cdrom dialout dialout libvirtd libvirtd 
lpadmin lpadmin plugdev plugdev rrdsock rrdsock sambashare sambashare sudo sudo 
trac

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Bug 930330] [NEW] gnome-keyring-daemon leaks memory badly

2012-02-10 Thread Alex Bennee 
Public bug reported:

There seems to be a persistent leak in gnome-keyring-daemon. Several
times I've come into work to find a very sluggish machine swapping
applications back in with the daemon consuming 45% of my system memory
(according to htop on an 8GB machine). If there is any debugging tips to
be offered on how to run the daemon outside of gnome-shell please let me
know and I can valgrind it for you.

Currently it's taking up a modest 510M of VIRT (238M RES), I expect this to be 
much more when I come back into the office on Monday.
--- 
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
DistroRelease: Ubuntu 11.10
InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
Package: gnome-keyring 3.2.2-0ubuntu0.1
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 LANGUAGE=en_GB.UTF-8
 LC_CTYPE=en_GB.UTF-8
ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
Tags:  oneiric
Uname: Linux 3.0.0-16-generic x86_64
UpgradeStatus: Upgraded to oneiric on 2011-11-04 (98 days ago)
UserGroups: adm adm admin admin cdrom cdrom dialout dialout libvirtd libvirtd 
lpadmin lpadmin plugdev plugdev rrdsock rrdsock sambashare sambashare sudo sudo 
trac

** Affects: gnome-keyring (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: apport-collected oneiric

** Tags added: apport-collected oneiric

** Description changed:

  There seems to be a persistent leak in gnome-keyring-daemon. Several
  times I've come into work to find a very sluggish machine swapping
  applications back in with the daemon consuming 45% of my system memory
  (according to htop on an 8GB machine). If there is any debugging tips to
  be offered on how to run the daemon outside of gnome-shell please let me
  know and I can valgrind it for you.
  
- Currently it's taking up a modest 510M of VIRT (238M RES), I expect this
- to be much more when I come back into the office on Monday.
+ Currently it's taking up a modest 510M of VIRT (238M RES), I expect this to 
be much more when I come back into the office on Monday.
+ --- 
+ ApportVersion: 1.23-0ubuntu4
+ Architecture: amd64
+ DistroRelease: Ubuntu 11.10
+ InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
+ Package: gnome-keyring 3.2.2-0ubuntu0.1
+ PackageArchitecture: amd64
+ ProcEnviron:
+  SHELL=/bin/bash
+  PATH=(custom, user)
+  LANG=en_GB.UTF-8
+  LANGUAGE=en_GB.UTF-8
+  LC_CTYPE=en_GB.UTF-8
+ ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
+ Tags:  oneiric
+ Uname: Linux 3.0.0-16-generic x86_64
+ UpgradeStatus: Upgraded to oneiric on 2011-11-04 (98 days ago)
+ UserGroups: adm adm admin admin cdrom cdrom dialout dialout libvirtd libvirtd 
lpadmin lpadmin plugdev plugdev rrdsock rrdsock sambashare sambashare sudo sudo 
trac

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Bug 930330] Dependencies.txt

2012-02-10 Thread Alex Bennee 
apport information

** Attachment added: Dependencies.txt
   
https://bugs.launchpad.net/bugs/930330/+attachment/2730042/+files/Dependencies.txt

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Bug 930330] [NEW] gnome-keyring-daemon leaks memory badly

2012-02-10 Thread Alex Bennee 
Public bug reported:

There seems to be a persistent leak in gnome-keyring-daemon. Several
times I've come into work to find a very sluggish machine swapping
applications back in with the daemon consuming 45% of my system memory
(according to htop on an 8GB machine). If there is any debugging tips to
be offered on how to run the daemon outside of gnome-shell please let me
know and I can valgrind it for you.

Currently it's taking up a modest 510M of VIRT (238M RES), I expect this to be 
much more when I come back into the office on Monday.
--- 
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
DistroRelease: Ubuntu 11.10
InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
Package: gnome-keyring 3.2.2-0ubuntu0.1
PackageArchitecture: amd64
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 LANGUAGE=en_GB.UTF-8
 LC_CTYPE=en_GB.UTF-8
ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
Tags:  oneiric
Uname: Linux 3.0.0-16-generic x86_64
UpgradeStatus: Upgraded to oneiric on 2011-11-04 (98 days ago)
UserGroups: adm adm admin admin cdrom cdrom dialout dialout libvirtd libvirtd 
lpadmin lpadmin plugdev plugdev rrdsock rrdsock sambashare sambashare sudo sudo 
trac

** Affects: gnome-keyring (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: apport-collected oneiric

** Tags added: apport-collected oneiric

** Description changed:

  There seems to be a persistent leak in gnome-keyring-daemon. Several
  times I've come into work to find a very sluggish machine swapping
  applications back in with the daemon consuming 45% of my system memory
  (according to htop on an 8GB machine). If there is any debugging tips to
  be offered on how to run the daemon outside of gnome-shell please let me
  know and I can valgrind it for you.
  
- Currently it's taking up a modest 510M of VIRT (238M RES), I expect this
- to be much more when I come back into the office on Monday.
+ Currently it's taking up a modest 510M of VIRT (238M RES), I expect this to 
be much more when I come back into the office on Monday.
+ --- 
+ ApportVersion: 1.23-0ubuntu4
+ Architecture: amd64
+ DistroRelease: Ubuntu 11.10
+ InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100429)
+ Package: gnome-keyring 3.2.2-0ubuntu0.1
+ PackageArchitecture: amd64
+ ProcEnviron:
+  SHELL=/bin/bash
+  PATH=(custom, user)
+  LANG=en_GB.UTF-8
+  LANGUAGE=en_GB.UTF-8
+  LC_CTYPE=en_GB.UTF-8
+ ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
+ Tags:  oneiric
+ Uname: Linux 3.0.0-16-generic x86_64
+ UpgradeStatus: Upgraded to oneiric on 2011-11-04 (98 days ago)
+ UserGroups: adm adm admin admin cdrom cdrom dialout dialout libvirtd libvirtd 
lpadmin lpadmin plugdev plugdev rrdsock rrdsock sambashare sambashare sudo sudo 
trac

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 930330] Dependencies.txt

2012-02-10 Thread Alex Bennee 
apport information

** Attachment added: Dependencies.txt
   
https://bugs.launchpad.net/bugs/930330/+attachment/2730042/+files/Dependencies.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/930330

Title:
  gnome-keyring-daemon leaks memory badly

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/930330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 911693] Re: No debug symbols for git

2012-01-20 Thread Alex Bennee 
Does that make this an upstream bug for Debian?

I've also found another package without debug symbols (libgdk-
pixbuf2.0-0), should I raise a bug for that as well?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/911693

Title:
  No debug symbols for git

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/git/+bug/911693/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [rrd-developers] Distro patch to libtool on Debian Wheezy/Ubuntu Oneiric breaks compile of rrdtool (Was: Re: Compile failure due to libwrap on Ubuntu 11.10)

2012-01-10 Thread Alex Bennee 
On 5 January 2012 16:52, Kurt Roeckx k...@roeckx.be wrote:
 On Tue, Dec 20, 2011 at 05:33:51PM +, Alex Bennee wrote:
 On 20 December 2011 15:46, Tobias Oetiker t...@oetiker.ch wrote:
  Hi Alex,
 
  Yesterday Alex Bennee wrote:
 
  On 19 December 2011 17:00, Tobias Oetiker t...@oetiker.ch wrote:
   Alex,
  
   your system seems to be using a different version of  libtool ...
snip
  libtool gets created by libtoolize as far as I know ...

 OK after much bisecting I've narrowed it down to a patch in libtool
 2.4 added by Debian in
 libtool 2.4-1 The result moves the processing of dependancy_libs
 in libtool which breaks the passing of the flags in the subtle and
 maddening way discussed.

 Can you point me to that discussion?

Apologies for the delay, I've only just got back into work following
the birth of my daughter. GMane has split the discussion but you can
see it here:

http://thread.gmane.org/gmane.comp.db.rrdtool.devel/4132
http://thread.gmane.org/gmane.comp.db.rrdtool.devel/4155


 I've attached the libtool patch for reference.
snip

 The patch prevents reading the dependancy_libs for cases it
 shouldn't read it, and so avoids unneeded linking to libraries.

Well in this case dependancy_libs should have -lwrap in them but it
get squashed. However it could be that RRDTool's autoconf magic is
incorrect in the way is specifies libwrap:

http://oss.oetiker.ch/rrdtool-trac/browser/trunk/program/configure.ac?rev=2247#L105

 My guess would be that you expect to be able to save linker flags
 in dependancy_libs, but I can't think of a good reason why you
 would want to do that.

Isn't this all driven by autotools? The only slight weirdness is
rrdcached uses a different .la file (librrd_th):

http://oss.oetiker.ch/rrdtool-trac/browser/trunk/program/src/Makefile.am?rev=2247#L116

But I thought the .la files where set up by autotools so should Do The
Right Thing (tm). However it's entirely possible the automagic is
being set-up wrong. Any advice gratefully received. I'm kinda lost
digging through the rabbit hole that is the autogenerated scripts and
makefiles which is why I went to the source.

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

___
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

Re: Distro patch to libtool on Debian Wheezy/Ubuntu Oneiric breaks compile of rrdtool (Was: Re: [rrd-developers] Compile failure due to libwrap on Ubuntu 11.10)

2012-01-10 Thread Alex Bennee 
On 5 January 2012 16:52, Kurt Roeckx k...@roeckx.be wrote:
 On Tue, Dec 20, 2011 at 05:33:51PM +, Alex Bennee wrote:
 On 20 December 2011 15:46, Tobias Oetiker t...@oetiker.ch wrote:
  Hi Alex,
 
  Yesterday Alex Bennee wrote:
 
  On 19 December 2011 17:00, Tobias Oetiker t...@oetiker.ch wrote:
   Alex,
  
   your system seems to be using a different version of  libtool ...
snip
  libtool gets created by libtoolize as far as I know ...

 OK after much bisecting I've narrowed it down to a patch in libtool
 2.4 added by Debian in
 libtool 2.4-1 The result moves the processing of dependancy_libs
 in libtool which breaks the passing of the flags in the subtle and
 maddening way discussed.

 Can you point me to that discussion?

Apologies for the delay, I've only just got back into work following
the birth of my daughter. GMane has split the discussion but you can
see it here:

http://thread.gmane.org/gmane.comp.db.rrdtool.devel/4132
http://thread.gmane.org/gmane.comp.db.rrdtool.devel/4155


 I've attached the libtool patch for reference.
snip

 The patch prevents reading the dependancy_libs for cases it
 shouldn't read it, and so avoids unneeded linking to libraries.

Well in this case dependancy_libs should have -lwrap in them but it
get squashed. However it could be that RRDTool's autoconf magic is
incorrect in the way is specifies libwrap:

http://oss.oetiker.ch/rrdtool-trac/browser/trunk/program/configure.ac?rev=2247#L105

 My guess would be that you expect to be able to save linker flags
 in dependancy_libs, but I can't think of a good reason why you
 would want to do that.

Isn't this all driven by autotools? The only slight weirdness is
rrdcached uses a different .la file (librrd_th):

http://oss.oetiker.ch/rrdtool-trac/browser/trunk/program/src/Makefile.am?rev=2247#L116

But I thought the .la files where set up by autotools so should Do The
Right Thing (tm). However it's entirely possible the automagic is
being set-up wrong. Any advice gratefully received. I'm kinda lost
digging through the rabbit hole that is the autogenerated scripts and
makefiles which is why I went to the source.

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

[Bug 911693] [NEW] No debug symbols for git

2012-01-04 Thread Alex Bennee 
Public bug reported:

I'm trying to do some system profiling on a server that's behaving
poorly while cloning repositories. To do proper profiling I need the
debug symbols but I can find them even with the ddebs.ubuntu.com repo
added.


root@vsbldhost:/scratch/root# apt-cache search dbg | grep git
gtkam-dbg - GTK+ application for digital still cameras (debugging symbols)
jigit-dbgsym - debug symbols for package jigit
gitg-dbgsym - debug symbols for package gitg
digitemp-dbgsym - debug symbols for package digitemp
logitech-applet-dbgsym - debug symbols for package logitech-applet
flegita-gimp-dbgsym - debug symbols for package flegita-gimp
callgit-dbgsym - debug symbols for package callgit
engauge-digitizer-dbgsym - debug symbols for package engauge-digitizer
qgit-dbgsym - debug symbols for package qgit
sigit-dbgsym - debug symbols for package sigit
flegita-dbgsym - debug symbols for package flegita
digitools-dbgsym - debug symbols for package digitools

I'm running Lucid LTS

root@vsbldhost:/scratch/root# lsb_release -rd
Description:Ubuntu 10.04.3 LTS
Release:10.04

root@vsbldhost:/scratch/root# apt-cache policy git-core
git-core:
  Installed: 1:1.7.0.4-1ubuntu0.2
  Candidate: 1:1.7.0.4-1ubuntu0.2
  Version table:
 *** 1:1.7.0.4-1ubuntu0.2 0
500 http://gb.archive.ubuntu.com/ubuntu/ lucid-updates/main Packages
500 http://security.ubuntu.com/ubuntu/ lucid-security/main Packages
100 /var/lib/dpkg/status
 1:1.7.0.4-1 0
500 http://gb.archive.ubuntu.com/ubuntu/ lucid/main Packages

** Affects: git-core (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: debug

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/911693

Title:
  No debug symbols for git

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/911693/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [rrd-developers] Distro patch to libtool on Debian Wheezy/Ubuntu Oneiric breaks compile of rrdtool (Was: Re: Compile failure due to libwrap on Ubuntu 11.10)

2011-12-21 Thread Alex Bennee 
On 20 December 2011 20:08, Tobias Oetiker t...@oetiker.ch wrote:
 Hi Alex,

 Today Alex Bennee wrote:

snip

 OK after much bisecting I've narrowed it down to a patch in libtool
 2.4 added by Debian in
 libtool 2.4-1 The result moves the processing of dependancy_libs
 in libtool which breaks the passing of the flags in the subtle and
 maddening way discussed.

 :-) cool ... maybe I am not using the 'standard' way of adding
 libraries ? will be glad to adapt ...

I suspect you are as the build works fine using a vanilla libtool from the
git repo. It's the patching done by Debian that regressed the behaviour.

What is your normal build system?

 I've attached the libtool patch for reference. Once I've figured out
 what it's trying to achieve
 I'll raise a bug with Debian/Ubuntu to fix their libtool and then
 we'll finally be able to build a newer
 rrdtool on Debian.

 note on the rrdtool webpage there is a daily snapshot of rrdtool
 including all the configure stuff ...

Hmm good point. My Debian packaging was working straight of the
git-svn mirror of your upstream. Most packages work from the dist
tarball which includes all the configure junk. Having said that I think
there is a general move to moving more packaging to track upstream
repositories within some sort of version control because it makes it
easier for the maintainer to push patches upstream.

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

___
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

[rrd-developers] Distro patch to libtool on Debian Wheezy/Ubuntu Oneiric breaks compile of rrdtool (Was: Re: Compile failure due to libwrap on Ubuntu 11.10)

2011-12-20 Thread Alex Bennee 
On 20 December 2011 15:46, Tobias Oetiker t...@oetiker.ch wrote:
 Hi Alex,

 Yesterday Alex Bennee wrote:

 On 19 December 2011 17:00, Tobias Oetiker t...@oetiker.ch wrote:
  Alex,
 
  your system seems to be using a different version of  libtool ...
  so did you run MakeMakefile ?

 No, isn't that part of the configure/autogen stuff?

 MakeMakefile calls the auto* tools in a way so that all the right
 bits get put into place ...

 libtool gets created by libtoolize as far as I know ...

OK after much bisecting I've narrowed it down to a patch in libtool
2.4 added by Debian in
libtool 2.4-1 The result moves the processing of dependancy_libs
in libtool which breaks the passing of the flags in the subtle and
maddening way discussed.

I've attached the libtool patch for reference. Once I've figured out
what it's trying to achieve
I'll raise a bug with Debian/Ubuntu to fix their libtool and then
we'll finally be able to build a newer
rrdtool on Debian.

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk
Index: libtool-2.4/libltdl/config/ltmain.m4sh
===
--- libtool-2.4.orig/libltdl/config/ltmain.m4sh	2011-03-27 21:52:59.0 +
+++ libtool-2.4/libltdl/config/ltmain.m4sh	2011-03-27 22:06:06.0 +
@@ -5644,19 +5644,19 @@
 	# It is a libtool convenience library, so add in its objects.
 	func_append convenience  $ladir/$objdir/$old_library
 	func_append old_convenience  $ladir/$objdir/$old_library
+	tmp_libs=
+	for deplib in $dependency_libs; do
+	  deplibs=$deplib $deplibs
+	  if $opt_preserve_dup_deps ; then
+		case $tmp_libs  in
+		* $deplib *) func_append specialdeplibs  $deplib ;;
+		esac
+	  fi
+	  func_append tmp_libs  $deplib
+	done
 	  elif test $linkmode != prog  test $linkmode != lib; then
 	func_fatal_error \`$lib' is not a convenience library
 	  fi
-	  tmp_libs=
-	  for deplib in $dependency_libs; do
-	deplibs=$deplib $deplibs
-	if $opt_preserve_dup_deps ; then
-	  case $tmp_libs  in
-	  * $deplib *) func_append specialdeplibs  $deplib ;;
-	  esac
-	fi
-	func_append tmp_libs  $deplib
-	  done
 	  continue
 	fi # $pass = conv
 
___
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

Re: [rrd-developers] Compile failure due to libwrap on Ubuntu 11.10

2011-12-19 Thread Alex Bennee 
On 19 December 2011 16:04, Tobias Oetiker t...@oetiker.ch wrote:
 Today Alex Bennee wrote:
 In fact without the attached patch I see a failure in eval while
 running configure:

 Test Library Functions
 checking for acos... no
 checking for acos in -lm... yes
 checking for round... yes
 ./configure: eval: line 13465: unexpected EOF while looking for matching `'
 ./configure: eval: line 13466: syntax error: unexpected end of file

 The code looks like:

 eval `./libtool --config | grep pic_flag`
 CFLAGS=$CFLAGS $pic_flag

 ok, applied your patch ...

 what did

 ./libtool --config | grep pic_flag

 return on your system?

It's in the patch. I get:

16:07 ajb@sloy/x86_64 [rrdtool.git-svn] ./libtool --config | grep pic_flag
pic_flag= -fPIC -DPIC
archive_cmds=\$CC -shared \$pic_flag \$libobjs \$deplibs
\$compiler_flags \${wl}-soname \$wl\$soname -o \$lib
\$CC -shared \$pic_flag \$libobjs \$deplibs
\$compiler_flags \${wl}-soname \$wl\$soname \${wl}-version-script
\${wl}\$output_objdir/\$libname.ver -o \$lib


 also, what does configure report once it has run through.
Config is DONE!

  With MMAP IO: yes
  Build rrd_getopt: no
   Build rrd_graph: yes
   Static programs: no
  Perl Modules: perl_piped perl_shared
   Perl Binary: /usr/bin/perl
  Perl Version: 5.12.4
  Perl Options: PREFIX=/opt/rrdtool-1.4.999
LIB=/opt/rrdtool-1.4.999/lib/perl/5.12.4
  Ruby Modules: ruby
   Ruby Binary: /usr/bin/ruby
  Ruby Options: sitedir=/opt/rrdtool-1.4.999/lib/ruby
Build Lua Bindings: yes
Lua Binary: /usr/bin/lua
   Lua Version: 5.1.4
 Lua C-modules dir: /opt/rrdtool-1.4.999/lib/lua/5.1
Build Tcl Bindings: yes
 Build Python Bindings: yes
  Build rrdcgi: yes
   Build librrd MT: yes
   Use gettext: yes
   With libDBI: yes
  With libwrap: yes

 Libraries: -lxml2 -lglib-2.0 -lcairo -lcairo -lcairo -lm
-lwrap -ldbi -ldl -lcairo -lpng12   -lpangocairo-1.0 -lpango-1.0
-lcairo -lgobject-2.0 -lglib-2.0

On a side note, are you IRC anywhere at the moment? We might get
faster back and forth, although you currently have my attention for at
least the next 2 hours ;-)

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

___
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

Re: [rrd-developers] Compile failure due to libwrap on Ubuntu 11.10

2011-12-19 Thread Alex Bennee 
On 19 December 2011 17:00, Tobias Oetiker t...@oetiker.ch wrote:
 Alex,

 your system seems to be using a different version of  libtool ...
 so did you run MakeMakefile ?

No, isn't that part of the configure/autogen stuff?

Regardless running it now makes no difference.

The libtool on this system is:

17:09 ajb@sloy/x86_64 [rrdtool.git-svn] dpkg --status libtool
Package: libtool
snip
Version: 2.4-2ubuntu1

Although obviously the 1.4.3 package  (pre-libwrap) stuff builds fine
under this setup.

I'm a little unclear as to where the libtool script comes from. Is it
all driven from autoconf
magic in the rrd distribution or also influenced by the system
software installed? The resulting
libtool script between 1.4.3 and trunk seem quite big despite the
relatively few tweaks to
configure.ac. Is there anything else that influences how libtool gets built?

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

___
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

Re: [rrd-developers] Compile failure due to libwrap on Ubuntu 11.10

2011-12-16 Thread Alex Bennee 
On 12 December 2011 16:52, Tobias Oetiker t...@oetiker.ch wrote:
 Hi Alex,

 Today Alex Bennee wrote:

 On 8 November 2011 09:22, Alex Bennee kernel-hac...@bennee.com wrote:
  Hi,
 
  I've just recently updated to 11.10 and thought I'd get upto date on
  the trunk. It seems that there is some autotools breakage for libwrap.
  I get the following compile error:
 
  snip
  rrdcached-rrd_daemon.o: In function `connection_thread_main':
  /export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2657:
  undefined reference to `request_init'
  /export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2658:
  undefined reference to `sock_host'
  /export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2659:
  undefined reference to `hosts_access'
  /export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2660:
  undefined reference to `eval_client'
  /export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2660:
  undefined reference to `eval_client'
  collect2: ld returned 1 exit status
  make[2]: *** [rrdcached] Error 1
  make[2]: Leaving directory 
  `/export/csrc/packages/rrdtool/rrdtool.git-svn/src'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/export/csrc/packages/rrdtool/rrdtool.git-svn'
  make: *** [all] Error 2

 I take it from the radio silence no one else has come across this
 problem? For now I'll just switch back to the stable branch without
 the libwrap support. However I suspect this will need fixing when 1.6
 is released so things can be packaged appropriately.

 this looks as if you were missing tcp wrapper headers ... maybe
 this does not get checked explicitly in configure ... can you try
 installing them

Oh they are installed. It just seems somewhere in the libtool magic it
drops the needed link lines.

12:32 root@sloy/x86_64 [~] dpkg --status libwrap0-dev
Package: libwrap0-dev
Status: install ok installed



 Is there a plan for a release of 1.6 at some point?

 yes certainly ... it's just that the plan has no date yet :-)

 cheers
 tobi



 --
 Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
 http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900



-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

___
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

Re: [rrd-developers] Compile failure due to libwrap on Ubuntu 11.10

2011-12-16 Thread Alex Bennee 
On 16 December 2011 13:26, Tobias Oetiker t...@oetiker.ch wrote:
 Hi Alex,

 ah ...  I found something ... try changeing

 include tcpd.h

 into

 include tcpd.h

 in the configure script
 and run it again.

I'm afraid not:

make V=1
...
make[2]: Entering directory `/export/csrc/packages/rrdtool/rrdtool.git-svn/src'
/bin/sh ../libtool  --tag=CC   --mode=link gcc -g -O2 -D_GNU_SOURCE
-fno-strict-aliasing -Wall -std=gnu99 -pedantic -Wundef -Wshadow
-Wpointer-arith -Wcast-align -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -Winline
-Wold-style-definition -W  -fPIC -DPIC -g -O2 -D_GNU_SOURCE
-fno-strict-aliasing -Wall -std=gnu99 -pedantic -Wundef -Wshadow
-Wpointer-arith -Wcast-align -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -Winline
-Wold-style-definition -W  -fPIC -DPIC   -o rrdcached
rrdcached-rrd_daemon.o librrd_th.la
libtool: link: gcc -g -O2 -D_GNU_SOURCE -fno-strict-aliasing -Wall
-std=gnu99 -pedantic -Wundef -Wshadow -Wpointer-arith -Wcast-align
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline
-Wold-style-definition -W -fPIC -DPIC -g -O2 -D_GNU_SOURCE
-fno-strict-aliasing -Wall -std=gnu99 -pedantic -Wundef -Wshadow
-Wpointer-arith -Wcast-align -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -Winline
-Wold-style-definition -W -fPIC -DPIC -o .libs/rrdcached
rrdcached-rrd_daemon.o  ./.libs/librrd_th.so -pthread -Wl,-rpath
-Wl,/opt/rrdtool-1.6.0/lib
rrdcached-rrd_daemon.o: In function `connection_thread_main':
/export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2657:
undefined reference to `request_init'
/export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2658:
undefined reference to `sock_host'
/export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2659:
undefined reference to `hosts_access'
/export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2660:
undefined reference to `eval_client'
/export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2660:
undefined reference to `eval_client'
collect2: ld returned 1 exit status
make[2]: *** [rrdcached] Error 1
make[2]: Leaving directory `/export/csrc/packages/rrdtool/rrdtool.git-svn/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/export/csrc/packages/rrdtool/rrdtool.git-svn'
make: *** [all] Error 2

What is odd is the link flags are there in the .la file:

grep wrap src/librrd_th.la
dependency_libs=' -lpthread /usr/lib/libxml2.la -lm -lwrap
/usr/lib/libdbi.la -ldl -lpng12 -lpangocairo-1.0 -lpango-1.0
/usr/lib/x86_64-linux-gnu/libcairo.la -lgobject-2.0 -lglib-2.0'

But somehow the libtool script drops them. Unfortunately it's a mess
of bash which is hard to follow.

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

___
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

Re: [rrd-developers] Compile failure due to libwrap on Ubuntu 11.10

2011-12-12 Thread Alex Bennee 
On 8 November 2011 09:22, Alex Bennee kernel-hac...@bennee.com wrote:
 Hi,

 I've just recently updated to 11.10 and thought I'd get upto date on
 the trunk. It seems that there is some autotools breakage for libwrap.
 I get the following compile error:

 snip
 rrdcached-rrd_daemon.o: In function `connection_thread_main':
 /export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2657:
 undefined reference to `request_init'
 /export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2658:
 undefined reference to `sock_host'
 /export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2659:
 undefined reference to `hosts_access'
 /export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2660:
 undefined reference to `eval_client'
 /export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2660:
 undefined reference to `eval_client'
 collect2: ld returned 1 exit status
 make[2]: *** [rrdcached] Error 1
 make[2]: Leaving directory `/export/csrc/packages/rrdtool/rrdtool.git-svn/src'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/export/csrc/packages/rrdtool/rrdtool.git-svn'
 make: *** [all] Error 2

I take it from the radio silence no one else has come across this
problem? For now I'll just switch back to the stable branch without
the libwrap support. However I suspect this will need fixing when 1.6
is released so things can be packaged appropriately.

Is there a plan for a release of 1.6 at some point?

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

___
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

[Bug 890167] [NEW] Moonlight not available for Oneiric Ocelot

2011-11-14 Thread Alex Bennee 
Public bug reported:

Unfortunately I need Moonlight installed to use an internal intranet
site. After following link on the 'net I found a suggestion it should be
apt-get 'able.  However according to the package page:
http://packages.ubuntu.com/source/natty/moon there is no version built
for Oneirc. Ubuntu Updates seems to think that it was but got deleted
(http://www.ubuntuupdates.org/packages/show/345225). I've done a bit of
searching but couldn't find any announcement of Moonlight being dropped
from the repos which leaves the current state of Moonlight in Ubuntu as
confusing at best.

It should either be clearly documented as no longer supported or there
should be packages for Oneiric.

** Affects: moon (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: documentation missing

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/890167

Title:
  Moonlight not available for Oneiric Ocelot

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/moon/+bug/890167/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[rrd-developers] Compile failure due to libwrap on Ubuntu 11.10

2011-11-08 Thread Alex Bennee 
Hi,

I've just recently updated to 11.10 and thought I'd get upto date on
the trunk. It seems that there is some autotools breakage for libwrap.
I get the following compile error:

/bin/sh ../libtool  --tag=CC   --mode=link gcc -g -O2 -D_GNU_SOURCE
-fno-strict-aliasing -Wall -std=gnu99 -pedantic -Wundef -Wshadow
-Wpointer-arith -Wcast-align -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -Winline
-Wold-style-definition -W  -fPIC -DPIC -g -O2 -D_GNU_SOURCE
-fno-strict-aliasing -Wall -std=gnu99 -pedantic -Wundef -Wshadow
-Wpointer-arith -Wcast-align -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -Winline
-Wold-style-definition -W  -fPIC -DPIC   -o rrdcached
rrdcached-rrd_daemon.o librrd_th.la
libtool: link: gcc -g -O2 -D_GNU_SOURCE -fno-strict-aliasing -Wall
-std=gnu99 -pedantic -Wundef -Wshadow -Wpointer-arith -Wcast-align
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline
-Wold-style-definition -W -fPIC -DPIC -g -O2 -D_GNU_SOURCE
-fno-strict-aliasing -Wall -std=gnu99 -pedantic -Wundef -Wshadow
-Wpointer-arith -Wcast-align -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -Winline
-Wold-style-definition -W -fPIC -DPIC -o .libs/rrdcached
rrdcached-rrd_daemon.o  ./.libs/librrd_th.so -pthread -Wl,-rpath
-Wl,/opt/rrdtool-1.4.3/lib
rrdcached-rrd_daemon.o: In function `connection_thread_main':
/export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2657:
undefined reference to `request_init'
/export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2658:
undefined reference to `sock_host'
/export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2659:
undefined reference to `hosts_access'
/export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2660:
undefined reference to `eval_client'
/export/csrc/packages/rrdtool/rrdtool.git-svn/src/rrd_daemon.c:2660:
undefined reference to `eval_client'
collect2: ld returned 1 exit status
make[2]: *** [rrdcached] Error 1
make[2]: Leaving directory `/export/csrc/packages/rrdtool/rrdtool.git-svn/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/export/csrc/packages/rrdtool/rrdtool.git-svn'
make: *** [all] Error 2

Manually adding -lwrap to gcc fixes the problem. The autoconf magic is
detecting libwrap but I'm unsure how to ensure the link magic is
suitably set. The .la files contain references to it:

$ grep wrap src/librrd_th.la
dependency_libs=' -lpthread /usr/lib/libxml2.la -lwrap
/usr/lib/libdbi.la -lm -ldl -lpng12
/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.la
/usr/lib/x86_64-linux-gnu/libpango-1.0.la
/usr/lib/x86_64-linux-gnu/libcairo.la -lgobject-2.0 -lgmodule-2.0 -lrt
-lglib-2.0'

Can anyone with more knowledge of automagic point me in the right direction?

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

___
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

[Bug 882941] Re: Debmirror ignores '--method' option (always uses rsync)

2011-11-08 Thread Alex Bennee 
I can confirm this happens. A strace very clearly shows it ignoring me:


29077 execve(/usr/bin/debmirror, [debmirror, --host, sloy, 
--method=http, -r, apt, --dist=repo, --arch=amd64,source, 
--section=main, VNMS_2.1.32-0], [/* 83 vars */]) = 0
29078 execve(/bin/sh, [sh, -c, patch --version 2/dev/null /de...], 
[/* 83 vars */]) = 0
29079 execve(/usr/bin/patch, [patch, --version], [/* 81 vars */]) = 0
29078 --- SIGCHLD (Child exited) @ 0 (0) ---
29077 --- SIGCHLD (Child exited) @ 0 (0) ---
29080 execve(/bin/sh, [sh, -c, ed --version 2/dev/null /dev/n...], 
[/* 83 vars */]) = 0
29081 execve(/bin/ed, [ed, --version], [/* 81 vars */]) = 0
29080 --- SIGCHLD (Child exited) @ 0 (0) ---
29077 --- SIGCHLD (Child exited) @ 0 (0) ---
29082 execve(/bin/pwd, [/bin/pwd], [/* 83 vars */]) = 0
29077 --- SIGCHLD (Child exited) @ 0 (0) ---
29083 execve(/bin/sh, [sh, -c, hostname -f 2/dev/null || hostn...], 
[/* 83 vars */]) = 0
29084 execve(/bin/hostname, [hostname, -f], [/* 81 vars */]) = 0
29083 --- SIGCHLD (Child exited) @ 0 (0) ---
29077 --- SIGCHLD (Child exited) @ 0 (0) ---
29085 execve(/bin/sh, [sh, -c, rsync --timeout=300 -aL --partia...], 
[/* 83 vars */]) = 0
29085 execve(/usr/bin/rsync, [rsync, --timeout=300, -aL, --partial, 
--no-motd, sloy::apt/, --delete, --include-from=/tmp/hAhNFwYq2H, 
--exclude=*, /media/DaK/VNMS_UPGRADES/VNMS_2], [/* 81 vars */]) = 0
29077 --- SIGCHLD (Child exited) @ 0 (0) ---

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/882941

Title:
  Debmirror ignores '--method' option (always uses rsync)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debmirror/+bug/882941/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 882941] Re: Debmirror ignores '--method' option (always uses rsync)

2011-11-08 Thread Alex Bennee 
This looks like it's an upstream change. From the man-page:

  --rsync-extra=foo[,bar,..]
   Allows to also mirror files from a number of directories that are 
not part of the package archive itself.

   Debmirror will always use rsync for the transfer of these files, 
irrespective of what transfer method is
   specified in the --method option.  This will therefore not work if 
your remote mirror does not support rsync, or
   if the mirror needs a different --root option for rsync than for the 
main transfer method specified with
   --method.


However specifying --rsync-extra=none still fails on my setup with:

Download of dists/repo/Release failed: 500 Can't connect to sloy:80
(Connection refused)

Although looking at apache's logs I can see it never actually tried to
fetch the file.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/882941

Title:
  Debmirror ignores '--method' option (always uses rsync)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debmirror/+bug/882941/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: Problems with missing screen updates on recent version

2011-07-06 Thread Alex Bennee 
On 20 May 2011 17:15, Marc Lehmann schm...@schmorp.de wrote:
 On Fri, May 20, 2011 at 05:11:59PM +0100, Alex Bennee 
 kernel-hac...@bennee.com wrote:
 Yep, all my machines are Intel graphics so that would be a common
 factor. I don't
 suppose you have a bug reference for that?

 How come it hits urxvt so badly when I don't see obvious corruption 
 elsewhere?

 Nobody knows for sure, but urxvt tries very hard to avoid roundtrips
 (compare starting xterm and urxvt over a slow remote connection to see why
 :), so when x-servers forget to lock properly they might initiate e.g.
 some copying while the previous draw operation is still in progress, as
 urxvt tries hard to queue as many operations as possible.

I've updated the xorg-intel drivers on my Gentoo box at home to the
latest 2.15.0 drivers
and have seen a substantial improvement to urvt rendering on that machine.

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

___
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode

[Gwibber-bugs] [Bug 546877] Re: Gwibber not showing any tweets even after refreshing

2011-06-15 Thread Alex Bennee 
I have this problem as well with Gwibber 3.1.0 (via PPA) on Lucid. There
is some guff on start-up:


10:31 ajb@sloy/x86_64 [~] gwibber -o -d
ERROR:dbus.proxies:Introspect error on 
com.Gwibber.Streams:/com/gwibber/Streams: dbus.exceptions.DBusException: 
org.freedesktop.DBus.Error.ServiceUnknown: The name com.Gwibber.Streams was not 
provided by any .service files
ERROR:dbus.proxies:Introspect error on 
com.Gwibber.Accounts:/com/gwibber/Accounts: dbus.exceptions.DBusException: 
org.freedesktop.DBus.Error.ServiceUnknown: The name com.Gwibber.Accounts was 
not provided by any .service files
ERROR:dbus.proxies:Introspect error on 
com.Gwibber.Searches:/com/gwibber/Searches: dbus.exceptions.DBusException: 
org.freedesktop.DBus.Error.ServiceUnknown: The name com.Gwibber.Searches was 
not provided by any .service files
/usr/lib/python2.6/dist-packages/gwibber/gwui.py:753: GtkWarning: 
gtk_range_set_range: assertion `min  max' failed
  self.scrollbar.set_range(0, len(self.messages) - 1)
ERROR:dbus.proxies:Introspect error on 
com.Gwibber.Connection:/com/gwibber/Connection: dbus.exceptions.DBusException: 
org.freedesktop.DBus.Error.ServiceUnknown: The name com.Gwibber.Connection was 
not provided by any .service files
ERROR:dbus.proxies:Introspect error on 
com.Gwibber.Messages:/com/gwibber/Messages: dbus.exceptions.DBusException: 
org.freedesktop.DBus.Error.ServiceUnknown: The name com.Gwibber.Messages was 
not provided by any .service files
/usr/bin/gwibber:99: GtkWarning: gtk_container_add: assertion `GTK_IS_CONTAINER 
(container)' failed
  gtk.main()

But nothing shows after the Ctrl-r. In my case the individual Facebook
feed is showing but nothing for twitter, identica or Buzz. The combined
Home pane only shows Facebook status updates.

Posting seems unaffected though.


** Changed in: gwibber
   Status: Invalid = Confirmed

-- 
You received this bug notification because you are a member of Gwibber
Bug Heros, which is subscribed to Gwibber.
https://bugs.launchpad.net/bugs/546877

Title:
  Gwibber not showing any tweets even after refreshing

Status in Gwibber:
  Confirmed

Bug description:
  After installing Ubuntu Lucid gwibber is not showing any tweets even
  after creating the account

To manage notifications about this bug go to:
https://bugs.launchpad.net/gwibber/+bug/546877/+subscriptions

___
Mailing list: https://launchpad.net/~gwibber-bugs
Post to : gwibber-bugs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~gwibber-bugs
More help   : https://help.launchpad.net/ListHelp

Bug#630212: libvirt-bin: libvirt doesn't spawn qemu with supplementary groups

2011-06-12 Thread Alex Bennee 
Package: libvirt-bin
Version: 0.8.3-5+squeeze1
Severity: important
Tags: upstream


If you configure libvirt to spawn qemu with it's own user you can run into
problems getting KVM to work. This is because although the qemu user belongs
to the kvm and disk groups without calling initgroups the spawned process
won't be able to access /dev/kvm (root:kvm) and much hilarity/head scratching
will ensue.

This problem has been documented upstream and has been patched in recent 
releases:

https://bugzilla.redhat.com/show_bug.cgi?id=664406

In the end the workaround I applied was to nail the /dev/kvm device to:

ls -l /dev/kvm
crw-rw 1 root qemu 10, 232 Jun 12 11:51 /dev/kvm

And nailed it up with:

cat /etc/udev/rules.d/99-local-permissions.rules
# Make kvm available to qemu
KERNEL==kvm, GROUP=qemu, MODE=0660

-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [opennms-devel] Antw: Updated Node Map patches post OUCE2011

2011-06-01 Thread Alex Bennee 
On 1 June 2011 15:14, Michael Seibold michael.seib...@barmer-gek.de wrote:
 Hi Alex,

 great work!

 I want to contribute an idea for a little enhancement - getting the location 
 coordinates (longitude, latitude) from postal codes (I posted this 08.09.2009 
 to the discussion list as automatically generated Maps with a lot of 
 locations). Basically it would be a little add-on to your work. Maybe you or 
 someone at the Dev-Jam can add this so your patches.


I suspect not me. But maybe this is something to do in the RESTful
service that returns geolocation information?

 You can get the geographic locations with the use of postal codes, see 
 http://www.geonames.org/postal-codes/

 Download Postalcodes for your country, which is a rather small file: 
 http://download.geonames.org/export/zip/IT.zip

Hmm, it's going to depend on country. For example in the UK the
postcodes are copyrighted data.


 and add it to the postgres db so you don't need an online connection from 
 your network management to the internet (something I don't like...  and 
 besides, you don't want your network management to fail if some parts of your 
 net are not running, so a distributed network management application is no 
 use for me):

That would require the core developers consent. I doubt there is a
desire to overly bloat the OpenNMS data model.

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-devel mailing list

To *unsubscribe* or change your subscription options, see the bottom of this 
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel

Problems with missing screen updates on recent version

2011-05-09 Thread Alex Bennee 
Hi,

For a while now I've been noticing screen corruption and missing
updates on rxvt. The first thing I noticed was backspace wouldn't
always update the screen so characters wouldn't disappear until
another one was pressed. Even more corruption is noticeable if I
scroll in mutt or execute something with an ncurses interface like the
kernel menuconfig dialogues.

If I move the window from within X then everything corrects itself.
This makes me unsure if it's urxvt itself or one of the X libs in the
background getting confused.

My main machine is a Gentoo one but I'm running with the vanilla
flag to disable Gentoo's patches. I've also tried running from a plain
CVS checkout with the same problems. I'm now noticing similar problems
on Ubuntu 10.04 and 11.04 machines running with the latest urxvt
packages.

Can anyone suggest anything I can try to narrow down the potential
causes of the problem?

-- 
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk

___
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode

  1   2   3   4   5   6   >