Is there a gcc warning that we could enable to catch
these sort of problems?
Certainly it's something that any lint tool worth it's salt
would catch.
foo()
{
int retval = ERROR_OK;
{
/* can't we make GCC complain here?? */
int retval = ERROR_FAIL;
}
return retval;
}
--
Øyvind Harboe
US
On Mon, Jun 14, 2010 at 10:30 AM, Gabor Juhos juh...@openwrt.org wrote:
2010.06.14. 9:35 keltezéssel, Øyvind Harboe írta:
Is there a gcc warning that we could enable to catch
these sort of problems?
-Wshadow?
Yes, it catches them
That warning shows up some interesting cases e.g.
Hi
Yesterday I had a very brief chance to work with Samsung S3C2410A chip
and OpenOCD using a FT2232 based JTAG. There seems to be a serious
problem with some part of the S3C24xx code as in the beginning I was
totally unable to do any NAND Flash related stuff - doing nand probe 0
I always
The -c switch is not working for me, for any command I throw at it. Am I
missing something obvious?
I tried a quick bit of gdb but it disappears into the TCL code and I got scared.
$ openocd -c halt
Open On-Chip Debugger 0.5.0-dev-00274-ge212cf3 (2010-05-31-11:58)
Licensed under GNU GPL v2
For
I think it would be a good idea to have -Wshadow enabled by
default, it has uncovered several real bugs w.r.t. retval
today.
However, there are *many* places that need to be fixed in
the code for openocd to build without any -Wshadow warnings.
Three options come to mind:
1. don't enable it and
There isn't really any target support for that CPU in OpenOCD.
See the source.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
To support that chip for debugging,
we'd need specs for more of its
JTAG operations ... Atmel has not
made them public. (yet).
Meanwhile, I understand that you
can use OpenOCD to program flash
on such AVR8 chips... but not debug.
(Atmel did document those operations.)
Øyvind Harboe wrote:
I think it would be a good idea to have -Wshadow enabled by
default, it has uncovered several real bugs w.r.t. retval
today.
Agreed.
Three options come to mind:
1. don't enable it and wait for bugs to appear and fix them
one by one, possibly without -Wshadow help as
I think #3 sounds good (and turn on -Wshadow by default as soon as we
have reached a warning-free state - how many of those warnings are there
currently?)
Ca. 100?
I've fixed the real bugs that I've spotted today.
I wonder if there are real bugs in gdb-server.c, but I didn't
analyze it too
I made a stab at fixing most in jim.c, how do they look?
If these two patches are OK to be merged, then there is an interesting
residual case(line # after the two patches above are applied):
jim.c: In function ‘Jim_ScanCoreCommand’:
jim.c:11910: error: declaration of ‘count’ shadows a previous
Here is a patch to fix a startup in C100 (arm1136). Basically make sure
that UART is configured before using it.
Michal
diff --git a/tcl/target/c100helper.tcl b/tcl/target/c100helper.tcl
index 477fe5c..2a12c36 100644
--- a/tcl/target/c100helper.tcl
+++ b/tcl/target/c100helper.tcl
@@ -469,11
On Sun, Jun 13, 2010 at 8:22 AM, Stacey Sheldon s...@solidgoldbomb.org wrote:
Some ft2232 based devices (such as the FLOSS-JTAG) do
not include an on-board eeprom. Without an eeprom, the
devices do not have a unique serial number. When you
have multiple of these devices plugged into the same
On Fri, Jun 4, 2010 at 10:06 PM, Martin Zenzes
mzen...@informatik.uni-bremen.de wrote:
You can try libftdi-1.0 which is based on libusb-1.0.
jap, that helped. Thanks!
Just want to make it clear. Are you saying that libftdi-1.0
solved the following problem you have with FT2232?
Error:
Stacey Sheldon wrote:
This commit adds the 'ft2232_bus_addr' configuration
command which allows the user to specify the fully
qualified bus address of the ft2232 device.
I think this is a good addition, but..
The format of the address is the same as for the
equivalent -s option in lsusb
14 matches
Mail list logo
