Re: [Openocd-development] Cross Platform Debugger

On Mon, Dec 14, 2009 at 5:44 AM, David Brownell wrote: > On Sunday 13 December 2009, Michel Catudal wrote: >> I think that once OpenOCD is optimized it should work just as nice on >> the ARM (except for the lack of breakpoints) > > Recent ARMs don't share the "just two breakpoint/watchpoint units"

Re: [Openocd-development] OpenOCD Coding (was broken)

> One of the common threads there is needing to have a handle on > just how common an error is before choosing strategies for > dealing with it. I did a pass of OpenOCD in the early days where I fixed all the error paths for malloc() where malloc() was greater than a few bytes. I have no evidence

Re: [Openocd-development] Cross Platform Debugger

On Sunday 13 December 2009, Michel Catudal wrote: > I think that once OpenOCD is optimized it should work just as nice on > the ARM (except for the lack of breakpoints) Recent ARMs don't share the "just two breakpoint/watchpoint units" restriction of ARM7/ARM9 EmbeddedICE. Example, Cortex A8 and

Re: [Openocd-development] Cross Platform Debugger

Carsten Breuer a écrit : > Debugging was once cool with real emulators, with jtag, bdm or whatever, > it always sucks a bit. > > > Best Regards, > > > > Carsten > > I dislike the emulators. At work I have some projects with a Fujitsu processor and when I debug I need the $15k emulator to connec

Re: [Openocd-development] OpenOCD Coding (was broken)

On Sunday 13 December 2009, David Brownell wrote: > I admit that when I first came across it, the "don't check for NULL" > philosophy seemed pretty wrong.  But, quite a few years later on, now > I see that it's quite effective.  The "it's wrong" argument is on micro > scales.  The "it's right" one

Re: [Openocd-development] NAND: add erase_page callback

On Sunday 13 December 2009, Marek Vasut wrote: > > I'd send followup patch that'd clean that mess up altogether ... it's cleaner > and much easier to track back in git log. Go for it then. :) ___ Openocd-development mailing list Openocd-development@l

Re: [Openocd-development] OpenOCD Coding (was broken)

On Sunday 13 December 2009, Zach Welch wrote: > On Sun, 2009-12-13 at 15:49 -0800, David Brownell wrote: > [snip] > > > > Note that MISRA is not universally lauded. As I understand, some of > > > > its practices are contrary to other widely adopted coding policies. > > > > > > Sure. Some points

Re: [Openocd-development] NAND: add erase_page callback

Dne Ne 13. prosince 2009 21:06:32 David Brownell napsal(a): > On Sunday 13 December 2009, Marek Vasut wrote: > > > > > Either provide the > > > > > current logic in a separate routine that gets patched into the > > > > > ops vector of any driver that doesn't have it, or ... > > > > We can do so in

Re: [Openocd-development] OpenOCD Coding (was broken)

On Sun, 2009-12-13 at 15:49 -0800, David Brownell wrote: [snip] > > > Note that MISRA is not universally lauded. As I understand, some of > > > its practices are contrary to other widely adopted coding policies. > > > > Sure. Some points are a laugh like "a null pointer should not be > > derefer

Re: [Openocd-development] OpenOCD Coding (was broken)

On Sunday 13 December 2009, Carsten Breuer wrote: > If i have time i will make a check with lint and QAC and > if there are errors, i will submit patches. Great! Though try to filter out any that aren't going to be in the "obviously worth fixing" category and are more in the "debatable style choi

Re: [Openocd-development] OpenOCD Coding (was broken)

Hi David, i switch the subject to OpenOCD Coding, because this has nothing to do with the original posting anymore. > So if you have access to MISRA tools and specifications, which aren't > exactly public ... are you intending to submit any patches to address > related issues? If i have time i w

Re: [Openocd-development] OpenOCD broken

Hi David, hi all, first of all i have to say that it was not my intention to upset the developers here. Sorry. I was very happy that you fix the R13_svc bug in the second i had report it.. >> I agree. Nonetheless this error shouldn't occur in the official >> snapshot on the website. > I must hav

Re: [Openocd-development] arm11 srst behavior

On Monday 30 November 2009, Øyvind Harboe wrote: > I believe the problem with iMX31 is that it misbehaves after receiving > a TAP reset... I tried restoring the workaround for that (TLR) and added a comment about that being IMX-specific. Could you give this patch a try? - dave

Re: [Openocd-development] OpenOCD [not] broken

On Sun, Dec 13, 2009 at 11:41 PM, David Brownell wrote: > On Sunday 13 December 2009, Benjamin Schmidt wrote: >> Not sure if interesting to anyone, but I just ran svn head againt cppcheck... > > Much more relevant to see it against current git. > > The SVN tree is obsolete, nobody should be using

Re: [Openocd-development] OpenOCD broken

Can you find an example of a bug amongst these warnings? Or perhaps rate the top 5 most interesting findings? In Eclipse for Java there is something called a "quickfix" where you can tell the editor to fix a warning/error. Would be nice to have the same for C, e.g.: > [./src/jtag/vsllink.c:958]

Re: [Openocd-development] OpenOCD [not] broken

On Sunday 13 December 2009, David Brownell wrote: > On Sunday 13 December 2009, Benjamin Schmidt wrote: > > Not sure if interesting to anyone, but I just ran svn head againt > > cppcheck... > > Much more relevant to see it against current git. And to clarify why: several of those path names no

Re: [Openocd-development] OpenOCD [not] broken

On Sunday 13 December 2009, Benjamin Schmidt wrote: > Not sure if interesting to anyone, but I just ran svn head againt cppcheck... Much more relevant to see it against current git. The SVN tree is obsolete, nobody should be using it... ___ Openocd-dev

[Openocd-development] [patch/rfc] jtag: add '-ignore-version' option

Add a "-ignore-version" to "jtag newtap" which makes the IDCODE comparison logic optionally ignore version differences. Update the "scan_chain" command to illustrate this by showing a "*" character instead of the (ignored) version nibble. --- Various folk have mentioned this idea, and I figured it

Re: [Openocd-development] OpenOCD broken

Not sure if interesting to anyone, but I just ran svn head againt cppcheck... this is the result: [./contrib/libdcc/dcc_stdio.c:156]: (style) Warning - using char variable in bit operation [./src/flash/aduc702x.c:140]: (style) The scope of the variable x can be limited [./src/flash/aduc702x.c:1

Re: [Openocd-development] OpenOCD broken

On Sunday 13 December 2009, Carsten Breuer wrote: > What I dislike most: > > Missing brackets: > > if (FOO_BAR) >     do_something > > It should be > > if (FOO_BAR) > { >     do:something > } For the record: I dislike the superfluous brackets. As Lennart noted, wasting vertical space is not

Re: [Openocd-development] OpenOCD [not] broken

On Sunday 13 December 2009, Carsten Breuer wrote: > http://en.wikipedia.org/wiki/MISRA So if you have access to MISRA tools and specifications, which aren't exactly public ... are you intending to submit any patches to address related issues? Or maybe at least post the results of some MISRA analy

Re: [Openocd-development] OpenOCD broken

On Sunday 13 December 2009, Carsten Breuer wrote: > I agree. Nonetheless this error shouldn't occur in the official > snapshot on the website. I must have missed the notice that *during the merge window* it became reasonable to treat arbitrary snapshots as being release quality. Could you point o

Re: [Openocd-development] OpenOCD broken

On Sun, Dec 13, 2009 at 10:29:36PM +0100, Carsten Breuer wrote: > > You could also argue that the do_something definition is buggy, > > since it's not one statement. > > Correct. But if you use brackets the code do what you want and > you get the result what you expect. Sure, but if you use brac

Re: [Openocd-development] OpenOCD broken

> You could also argue that the do_something definition is buggy, > since it's not one statement. Correct. But if you use brackets the code do what you want and you get the result what you expect. Lint complains about both. > E.g. the Linux kernel takes this stance, and wraps such macros in do >

Re: [Openocd-development] OpenOCD broken

On Sun, Dec 13, 2009 at 09:53:42PM +0100, Carsten Breuer wrote: > What I dislike most: > > Missing brackets: > > if (FOO_BAR) > do_something > > It should be > > if (FOO_BAR) > { > do:something > } > > because if do_something is defined like follows: > > #define do_something a=10; b

Re: [Openocd-development] Cross Platform Debugger

Hi Michael, hi all > There is setedit that uses gdb. I haven't tried the one on windows Cool :-). Looks like Borland C++ 3.1, that i have used some decades ago with DOS 5.0 :-))). Since i use midnight commander a lot, this is really an option :-). >> kdbg would be nicer. insight sucks. If someon

Re: [Openocd-development] OpenOCD broken

> -Wall is the minimum that should be applied to source code. Running > it through Splint (or some other verification tool) would not hurt > either. That's true. Nonetheless some people are too lazy to make a distclean first ;-). Splint is t buggy to use it. At work we use pclint from gimple w

Re: [Openocd-development] OpenOCD broken

Hi, > This is a good thing to have as a default behavior, we want warning > fixes fed back. It cleans up the code and finds real bugs. I agree. Nonetheless this error shouldn't occur in the official snapshot on the website. > You *can* disable error on warnings at configure time. I prefered too

[Openocd-development] [patch 2/2] target files shouldn't #include

Make these ".h" files adopt the same policy the ".c" files already follow: don't use syntax for private interfaces. If we ever get reviewed/supported "public" interfaces they should come exclusively from some include/... directory. --- src/target/arm.h |2 +- src/target/arm11.h

[Openocd-development] [patch 1/2] target: further shrink Jim-awareness

Don't include from target.h ... not everything which touches targets needs to be able to talk to Jim. Also, most files include this header by another path. Also, switch the affected files to use the classic sequence for #included files: all first, then the "local_headers.h". This strategy hel

Re: [Openocd-development] NAND: add erase_page callback

On Sunday 13 December 2009, Marek Vasut wrote: > > > > > > Either provide the > > > > current logic in a separate routine that gets patched into the > > > > ops vector of any driver that doesn't have it, or ... > > We can do so in one go in a separate patch if you want to do this kind of > clean

Re: [Openocd-development] OpenOCD broken

their cvs has been updated according to sourceforge somewhat recently. they haven't done a release in two years, though. On 12/13/09, Albert ARIBAUD wrote: > Øyvind Harboe a écrit : >> On Sun, Dec 13, 2009 at 3:04 PM, Albert ARIBAUD >> wrote: >>> Øyvind Harboe a écrit : >>> > -Wall is the m

Re: [Openocd-development] OpenOCD broken

Albert ARIBAUD a écrit : > Also note splint has not been updated for a long time, as I discovered > when going to its home site. There are some alternatives mentioned on Wikipedia: I like clang's way of reporting errors, a

Re: [Openocd-development] OpenOCD broken

Øyvind Harboe a écrit : > On Sun, Dec 13, 2009 at 3:04 PM, Albert ARIBAUD > wrote: >> Øyvind Harboe a écrit : >> -Wall is the minimum that should be applied to source code. Running it through Splint (or some other verification tool) would not hurt either. >>> Is there an open source lin

Re: [Openocd-development] OpenOCD broken

On Sun, Dec 13, 2009 at 3:04 PM, Albert ARIBAUD wrote: > Øyvind Harboe a écrit : > >>> -Wall is the minimum that should be applied to source code. Running it >>> through Splint (or some other verification tool) would not hurt either. >> >> Is there an open source lint tool that's worthwhile to use

Re: [Openocd-development] OpenOCD broken

Øyvind Harboe a écrit : >> -Wall is the minimum that should be applied to source code. Running it >> through Splint (or some other verification tool) would not hurt either. > > Is there an open source lint tool that's worthwhile to use? > > Did you try splint on OpenOCD? Apart from Splint, I ha

Re: [Openocd-development] OpenOCD broken

On Sun, Dec 13, 2009 at 2:45 PM, Albert ARIBAUD wrote: > Øyvind Harboe a écrit : >> >> On Sun, Dec 13, 2009 at 12:13 AM, Carsten Breuer >> wrote: >>> >>> Hi all, >>> >>> >>> "treat warning as errors" (-wall) is a fine thing but sometimes breaks >>> the build.. >> >> This is a good thing to have a

Re: [Openocd-development] OpenOCD broken

Øyvind Harboe a écrit : > On Sun, Dec 13, 2009 at 12:13 AM, Carsten Breuer > wrote: >> Hi all, >> >> >> "treat warning as errors" (-wall) is a fine thing but sometimes breaks >> the build.. > > This is a good thing to have as a default behavior, we want warning > fixes fed back. It cleans up the

Re: [Openocd-development] OpenOCD broken

On Sun, Dec 13, 2009 at 12:13 AM, Carsten Breuer wrote: > Hi all, > > > "treat warning as errors" (-wall) is a fine thing but sometimes breaks > the build.. This is a good thing to have as a default behavior, we want warning fixes fed back. It cleans up the code and finds real bugs. You *can* di

Re: [Openocd-development] NAND: add erase_page callback

Dne Ne 13. prosince 2009 06:36:47 David Brownell napsal(a): > On Saturday 12 December 2009, Marek Vasut wrote: > > > Also, can you restructure it so that you don't just add a bit > > > "if (there's a custom erase_page) { ... }"? That's the sort > > > of thing which is easier to just require. > > >