> Actually, let me ask a very naive question: Can one even use a
> debugger with a largish process/OS like the AM335x/linux? I
> mean, what happens if you break in some time-critical portion
> of the linux kernel?
>
> --RY
>
Assuming it's even possible... seems like it might be...
http://www.linux.com/learn/linux-training/33991-the-kernel-newbie-corner-kernel-and-module-debugging-with-gdb
I find Eclipse/GDB tedious and don't use them. This way,
all my debug cruft is available should i need it at a site.
I'd rather pull the code out and run it in a test harness
on a workstation for unit test, then put the code into a driver
module. Yeah, I'll spend some time making test vectors
and updating them from inferred or logged operation of the driver.
> Randy Yates <yates@digitalsignallabs.com> writes:
>
>> Mike Perkins <spam@spam.com> writes:
>>> [...]
>>> Coupled with Eclipse, OpenOCD (though reverted back to 0.6.0 due to
>>> bugs) I feel I have a pleasant and effective IDE.
>>
>> I get very confused on which JTAGs/debugger interfaces OpenOCD will work
>> with. E.g., how about the following (some of my immediate work and/or
>> possibilities):
>>
>> 1. TI Tiva tm4c1294ncpdt
>>
>> 2. Freescale Coldfire MCF52235
>>
>> 3. Freescale Ketis K6x
>>
>> 4. TI Sitara AM335x
>>
>> ???
>
--
Les Cargill
Reply by Tauno Voipio●May 19, 20142014-05-19
On 19.5.14 17:17, Grant Edwards wrote:
>> I mean, what happens if you break in some time-critical portion of
>> the linux kernel?
>
> Good question.
>
> In theory it _might_ be useful for kernel debugging, but Linux has
> other facilities for that.
>
There is a special version of GDB, kgdb for kernel debugging.
--
Tauno Voipio
Reply by Grant Edwards●May 19, 20142014-05-19
On 2014-05-19, Randy Yates <yates@digitalsignallabs.com> wrote:
> Actually, let me ask a very naive question: Can one even use a
> debugger with a largish process/OS like the AM335x/linux?
I can't imagine how it would be useful for application development.
For that, you run gdb-server on the target and then the gdb front-end
on a desktop/laptop. [Actually, I generally do most of my debugging
by running the application on a desktop before I try to run the app on
target hardware.]
A JTAG debugger might be useful for debugging initialization and
startup code. It's certainly useful for troubleshooting and testing
hardware.
> I mean, what happens if you break in some time-critical portion of
> the linux kernel?
Good question.
In theory it _might_ be useful for kernel debugging, but Linux has
other facilities for that.
--
Grant Edwards grant.b.edwards Yow! I'm having a BIG BANG
at THEORY!!
gmail.com
Reply by Paul Rubin●May 19, 20142014-05-19
Randy Yates <yates@digitalsignallabs.com> writes:
> Actually, let me ask a very naive question: Can one even use a
> debugger with a largish process/OS like the AM335x/linux? I
> mean, what happens if you break in some time-critical portion
> of the linux kernel?
You mean to debug the kernel? Or a user-level application? You can use
gdb at user level and that's usually enough. I don't know about
debugging kernels on those boards though.
Reply by Randy Yates●May 19, 20142014-05-19
Actually, let me ask a very naive question: Can one even use a
debugger with a largish process/OS like the AM335x/linux? I
mean, what happens if you break in some time-critical portion
of the linux kernel?
--RY
Randy Yates <yates@digitalsignallabs.com> writes:
> Mike Perkins <spam@spam.com> writes:
>> [...]
>> Coupled with Eclipse, OpenOCD (though reverted back to 0.6.0 due to
>> bugs) I feel I have a pleasant and effective IDE.
>
> I get very confused on which JTAGs/debugger interfaces OpenOCD will work
> with. E.g., how about the following (some of my immediate work and/or
> possibilities):
>
> 1. TI Tiva tm4c1294ncpdt
>
> 2. Freescale Coldfire MCF52235
>
> 3. Freescale Ketis K6x
>
> 4. TI Sitara AM335x
>
> ???
> [...]
> Coupled with Eclipse, OpenOCD (though reverted back to 0.6.0 due to
> bugs) I feel I have a pleasant and effective IDE.
I get very confused on which JTAGs/debugger interfaces OpenOCD will work
with. E.g., how about the following (some of my immediate work and/or
possibilities):
1. TI Tiva tm4c1294ncpdt
2. Freescale Coldfire MCF52235
3. Freescale Ketis K6x
4. TI Sitara AM335x
???
--
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com
Reply by David Brown●May 18, 20142014-05-18
On 18/05/14 00:20, boB wrote:
> On Thu, 15 May 2014 23:49:50 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
>
>> On 15/05/14 21:02, Arlet Ottens wrote:
>>> On 05/15/2014 08:05 PM, boB wrote:
>>>
>>>>>> But doesn't IAR and Keil have 15 to 20% better code compiling
>>>>>> efficiency for size and speed over GCC ? That is what I have heard
>>>>>> anyway.
>>>>>
>>>>> Who told you that? IAR or Keil? Both are well known for using
>>>>> out-of-date versions of gcc and carefully picked samples to "prove" how
>>>>> much better they are than gcc. They are wary about using the same
>>>>> tricks against each others (or alternatives such as GHS), because they
>>>>> will get sued - but condemning gcc is fair game in the eyes of their
>>>>> marketing folk. No one independent can give any sort of objective
>>>>> comparisons, because the licensing for IAR, Keil (and most other
>>>>> commercial compilers for most targets) forbids it - and if anyone with
>>>>> any influence tried it, they would be sued.
>>>>>
>>>>> In reality, it is not unlikely that you will get 15-20% smaller and/or
>>>>> faster code with IAR or Keil than gcc for /some/ code samples - and gcc
>>>>> will be smaller and/or faster for others. The variation can be
>>>>> significant, and it can depend on small details in the code, and details
>>>>> in the code generation options. But there is certainly no general rule
>>>>> that these compilers have better code generation than gcc. If you need
>>>>> to know real numbers, you have no choice but to try it out yourself on
>>>>> your own code.
>>>>
>>>>
>>>> Interesting info, thanks.
>>>> I don't think that 15 to 20% was from either of those companies but
>>>> was from a couple of people on the Yahoo LPC2000 tech list.
>>>>
>>>> I sure wish I could test the theory easily. I suppose I could strip
>>>> the code way down to try part of it though. I may have to sometime.
>>>>
>>>> I hate having to pay ransom and especially when a hard drive fails and
>>>> a software key goes kaput and IAR only replaces it once before they
>>>> want the many years of back-ransom $$.
>>>>
>>>> I would think though that some third party or someone would have done
>>>> what I would like to do and really compare 2 or 3 or those with a
>>>> semi-large project. I forsee a lot of time and effort to do that even
>>>> with C being a portable source format.
>>>>
>>>> I may try stripping a lot of code out and see if I can get my stuff to
>>>> compile with GCC.
>>>>
>>>
>>> Keep in mind that compiler efficiency is not the only thing. There can
>>> also be quite a bit of performance difference in the compiler libraries.
>>
>> And of course there are lots of other reasons to pick different
>> compilers - different library features, different debuggers, different
>> RTOS support, different profiling tools, different test quality
>> certifications, etc.
>>
>> You can't get third-party comparisons that can give more than a rough
>> idea - they cannot (normally) legally publish benchmarks from the big
>> commercial compilers, and they cannot test with /your/ code. The best
>> that can be done is a comparison with gcc, llvm, and "commercial
>> compiler 1", "commercial compiler 2", etc.
>
>
> That's OK. Since there are only 2 commercial compilers for ARM that I
> know of, and they are both pretty good AFAIK that title should work
> well for that.
For "big name" commercial ARM compilers, there is ARM/Keil (though it
will be replaced by llvm), IAR, Green Hills, CodeWarrior (though gcc is
the default now). There are also "small" commercial compilers such as
ImageCraft. I don't have a complete list, but that's 5 independent
commercial compilers for ARM that I know of.
I can't give any indication of their quality for code generation or as
tools in general (even if it was allowed by their licenses!) - I simply
haven't used them.
>
> So, from what I am hearing, nobody has done a comparison of a
> large-ish project that we can hear about here.
Correct. If you are planning a big project for which these tools are a
possible choice, it should not be hard to get evaluation versions - but
expect to spend quite a bit of your time if you want to get a fair test.
Looking back at the above, "unsupported" is wrong; forum support can be
adequate especially when the authors participate as in this case. And it
is gcc; the answer to any question I have had is a google search away in
any case.
>> Last time I looked it came with more
>> libraries than the free versions of codesourcery, e.g. hard floating
>> point for CM4.
>
> The slightly weird thing about that is that IIRC ARM contracted
> CodeSourcery to provide a free toolchain, but in order to not upset
> other compiler vendors, it could not include hardfp support.
Oh really? I did not know that. It is just an edit to a config file
anyway, when building from source ("multilibs"). This sort of nonsense
is annoying. I expect it is the reason the ST gcc code examples only
build with someones proprietary packaging of gcc. Instead of a Makefile,
say.
>> It comes with "newlib nano", an attempt to reduce the footprint of
>> newlib with e.g. option for no-floating point printf.
>
> ARM engineers have been feeding some of the optimizations back into
> Newlib. Newlib has I think always had integer-only versions of the
> formatted input and output functions (iprintf and friends), but they
> still have a pretty large footprint.
I think you use linker flags to choose a cut-down printf. Not sure of
the details, I use my own "formatted output" functions myself.
>
> -a
--
John Devereux
Reply by ●May 17, 20142014-05-17
On Thu, 15 May 2014 23:49:50 +0200, David Brown
<david.brown@hesbynett.no> wrote:
>On 15/05/14 21:02, Arlet Ottens wrote:
>> On 05/15/2014 08:05 PM, boB wrote:
>>
>>>>> But doesn't IAR and Keil have 15 to 20% better code compiling
>>>>> efficiency for size and speed over GCC ? That is what I have heard
>>>>> anyway.
>>>>
>>>> Who told you that? IAR or Keil? Both are well known for using
>>>> out-of-date versions of gcc and carefully picked samples to "prove" how
>>>> much better they are than gcc. They are wary about using the same
>>>> tricks against each others (or alternatives such as GHS), because they
>>>> will get sued - but condemning gcc is fair game in the eyes of their
>>>> marketing folk. No one independent can give any sort of objective
>>>> comparisons, because the licensing for IAR, Keil (and most other
>>>> commercial compilers for most targets) forbids it - and if anyone with
>>>> any influence tried it, they would be sued.
>>>>
>>>> In reality, it is not unlikely that you will get 15-20% smaller and/or
>>>> faster code with IAR or Keil than gcc for /some/ code samples - and gcc
>>>> will be smaller and/or faster for others. The variation can be
>>>> significant, and it can depend on small details in the code, and details
>>>> in the code generation options. But there is certainly no general rule
>>>> that these compilers have better code generation than gcc. If you need
>>>> to know real numbers, you have no choice but to try it out yourself on
>>>> your own code.
>>>
>>>
>>> Interesting info, thanks.
>>> I don't think that 15 to 20% was from either of those companies but
>>> was from a couple of people on the Yahoo LPC2000 tech list.
>>>
>>> I sure wish I could test the theory easily. I suppose I could strip
>>> the code way down to try part of it though. I may have to sometime.
>>>
>>> I hate having to pay ransom and especially when a hard drive fails and
>>> a software key goes kaput and IAR only replaces it once before they
>>> want the many years of back-ransom $$.
>>>
>>> I would think though that some third party or someone would have done
>>> what I would like to do and really compare 2 or 3 or those with a
>>> semi-large project. I forsee a lot of time and effort to do that even
>>> with C being a portable source format.
>>>
>>> I may try stripping a lot of code out and see if I can get my stuff to
>>> compile with GCC.
>>>
>>
>> Keep in mind that compiler efficiency is not the only thing. There can
>> also be quite a bit of performance difference in the compiler libraries.
>
>And of course there are lots of other reasons to pick different
>compilers - different library features, different debuggers, different
>RTOS support, different profiling tools, different test quality
>certifications, etc.
>
>You can't get third-party comparisons that can give more than a rough
>idea - they cannot (normally) legally publish benchmarks from the big
>commercial compilers, and they cannot test with /your/ code. The best
>that can be done is a comparison with gcc, llvm, and "commercial
>compiler 1", "commercial compiler 2", etc.
That's OK. Since there are only 2 commercial compilers for ARM that I
know of, and they are both pretty good AFAIK that title should work
well for that.
So, from what I am hearing, nobody has done a comparison of a
large-ish project that we can hear about here.
boB