ARM abort exceptions from C Code
xrando...@gmail.com
system?
Is trying to access a NULL pointer the only one?
int *a = NULL;
*a = 5;/* causes a data abort */
2. Is it possible for some C code to cause a prefetch abort?
Thanks
tum_
> 1. What are all ways in C Code may cause a data abort on an ARM
> system?
> Is trying to access a NULL pointer the only one?
>
> int *a = NULL;
> *a = 5;/* causes a data abort */
NULL is not the only one, accessing any invalid (for you system)
memory address should cause the data abort.
> 2. Is it possible for some C code to cause a prefetch abort?
not sure why you need this but if I wanted this I'd look in the
direction of calling a function via a pointer and modifying this
pointer to point to some garbage in memory...
Boudewijn Dijkstra
> On Apr 2, 3:48 pm, xrandomhac...@gmail.com wrote:
>> 1. What are all ways in C Code may cause a data abort on an ARM
>> system?
>> Is trying to access a NULL pointer the only one?
>>
>> int *a = NULL;
>> *a = 5;/* causes a data abort */
>
> NULL is not the only one, accessing any invalid (for you system)
> memory address should cause the data abort.
NULL is not very likely to cause a data abort. A pointer to an unaligned
address is not guaranteed to cause a data abort.
Are we talking about any ARM system, a specific set of architectures, a
specific set of cores or a specific set of implementations?
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
tum_
> Op Tue, 03 Apr 2007 10:12:47 +0200 schreef tum_ <atoumantsev_s...@mail.ru>:
>
> > On Apr 2, 3:48 pm, xrandomhac...@gmail.com wrote:
> >> 1. What are all ways in C Code may cause a data abort on an ARM
> >> system?
> >> Is trying to access a NULL pointer the only one?
>
> >> int *a = NULL;
> >> *a = 5;/* causes a data abort */
>
> > NULL is not the only one, accessing any invalid (for you system)
> > memory address should cause the data abort.
>
> NULL is not very likely to cause a data abort. A pointer to an unaligned
> address is not guaranteed to cause a data abort.
>
> Are we talking about any ARM system, a specific set of architectures, a
> specific set of cores or a specific set of implementations?
;-) No idea. I'd guess we're talking about OP's particular system, of
which we know nothing except that it's ARM based.
Obviously, no informative answer is possible to such a question, so I
just gave _some_ answer which might or not help the OP.
I've got two ARM based devices on my desk. One of them will generate a
data abort exception on an attempt to access NULL and/or unaligned
address, while the other will not.
xrando...@gmail.com
> On Apr 3, 9:21 am, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
<...snip>
> ;-) No idea. I'd guess we're talking about OP's particular system, of
> which we know nothing except that it's ARM based.
> Obviously, no informative answer is possible to such a question, so I
> just gave _some_ answer which might or not help the OP.
> I've got two ARM based devices on my desk. One of them will generate a
> data abort exception on an attempt to access NULL and/or unaligned
> address, while the other will not.
Likewise. I'm too far up to know. I'm an application programmer on
*some* ARM based system. But it does abort when trying to access a
NULL.
So Data abort may probably happen on
a. trying to dereference a NULL pointer
b. reading from an unaligned access
And a Prefetch Abort may probably happen on
a. a corrupt callback may cause a prefetch abort.
Anymore?
Actually why I started this thread is that I have just come to use
exceptions to trace the problems in code - see LR's value, add 4 to
it, go to that address in the debugger and you land up at the source
line with trouble. I just wanted to know what all to expect at the
actual source line.
Thanks
42Bastian Schick
>
>And a Prefetch Abort may probably happen on
>a. a corrupt callback may cause a prefetch abort.
Also the NULL pointer may cause this. On many ARM based systems, the
vectors are in RAM at 0 !!
So it is possible if dereferencing a structure that you
corrupt the interrupt vector:
struct a {
int r,u,s,p,a,res,i,f;
};
struct a *b = NULL;
b->i = 0x1033;
=> prefetch abort but related to a NULL pointer.
--
42Bastian
Do not email to bast...@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !
tum_
> On Apr 3, 4:32 pm, "tum_" <atoumantsev_s...@mail.ru> wrote:
>
> > On Apr 3, 9:21 am, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>
<...snip>
>
> Likewise. I'm too far up to know. I'm an application programmer on
> *some* ARM based system. But it does abort when trying to access a
> NULL.
... your email address suggests that you might be up to no good ;-) is
this the reason why you don't even know what is the system you're
"working" with? ;))
> So Data abort may probably happen on
> a. trying to dereference a NULL pointer
> b. reading from an unaligned access
>
> And a Prefetch Abort may probably happen on
> a. a corrupt callback may cause a prefetch abort.
>
> Anymore?
b. function prologue stores the LR on the stack and then the stack
gets corrupted.
c. calls between ARM and Thumb code with incorrect interworking
implementation (modes are not switched when needed).
> Actually why I started this thread is that I have just come to use
> exceptions to trace the problems in code - see LR's value, add 4 to
> it, go to that address in the debugger and you land up at the source
> line with trouble. I just wanted to know what all to expect at the
> actual source line.
>
> Thanks
What debugger are you using? How does it report exceptions to you? A
proper debugger can trap exceptions and show you the offending line/
instruction w/out you needing to calculate it from registers'
content...
xrando...@gmail.com
<...snip>
> ... your email address suggests that you might be up to no good ;-) is
> this the reason why you don't even know what is the system you're
> "working" with? ;))
I'm a program writer for a respectable software company. I have a
social security number, I pay my taxes, and I... help my landlady
carry out her garbage ;) hahaha
> > So Data abort may probably happen on
> > a. trying to dereference a NULL pointer
> > b. reading from an unaligned access
>
> > And a Prefetch Abort may probably happen on
> > a. a corrupt callback may cause a prefetch abort.
>
> > Anymore?
>
> b. function prologue stores the LR on the stack and then the stack
> gets corrupted.
This can be caused from any random memory corruption. Essentially any
kind of corruption that corrupts any rw part of the code.To debug one
would have to find the address that is corrupted and then watch the
data while debugging again, see who corrupts it. Tough! Tougher still
would be if the memory is corrupted in some kind of dma/h/w initiated
transfer. The data breakpoint would never hit.
> c. calls between ARM and Thumb code with incorrect interworking
> implementation (modes are not switched when needed).
Nothing a programmer can do to affect this, right? This has to be some
toolchain issue.
>
> > Actually why I started this thread is that I have just come to use
> > exceptions to trace the problems in code - see LR's value, add 4 to
> > it, go to that address in the debugger and you land up at the source
> > line with trouble. I just wanted to know what all to expect at the
> > actual source line.
>
> > Thanks
>
> What debugger are you using? How does it report exceptions to you? A
> proper debugger can trap exceptions and show you the offending line/
> instruction w/out you needing to calculate it from registers'
> content...
AFAIK it doesn't report exceptions per se, the exception handler
asserts. So I have a breakpoint at assert and i construct the stack
from there - actually i haven't done this but have seen someone do it,
this is just my recollection of it.
I'm using Lauterbach/Trace32
tum_
> On Apr 4, 12:30 am, "tum_" <atoumantsev_s...@mail.ru> wrote:
>
> I'm a program writer for a respectable software company. I have a
> social security number, I pay my taxes, and I... help my landlady
> carry out her garbage ;) hahaha
LOL.
> > b. function prologue stores the LR on the stack and then the stack
> > gets corrupted.
>
> This can be caused from any random memory corruption. Essentially any
> kind of corruption that corrupts any rw part of the code.To debug one
> would have to find the address that is corrupted and then watch the
> data while debugging again, see who corrupts it. Tough! Tougher still
> would be if the memory is corrupted in some kind of dma/h/w initiated
> transfer. The data breakpoint would never hit.
Not sure what you mean by 'data breakpoint' here. Anyway, yes,
debugging corruptions like this can be tough but they shouldn't happen
often in a properly designed system.
> > c. calls between ARM and Thumb code with incorrect interworking
> > implementation (modes are not switched when needed).
>
> Nothing a programmer can do to affect this, right? This has to be some
> toolchain issue.
Yes and no, depends on how much control do you have over the project
as "a programmer".
If you're allowed to change compiler options and/or libraries being
linked - you can well affect this.
Or if you decide to write a function in assembly...
> AFAIK it doesn't report exceptions per se, the exception handler
> asserts. So I have a breakpoint at assert and i construct the stack
> from there - actually i haven't done this but have seen someone do it,
> this is just my recollection of it.
>
> I'm using Lauterbach/Trace32
Lucky you... (However, Lauterbach have a range of products, if you're
lucky to have the full In-Circuit Emulator - then you just can't ask
for more). Does the 'a.l' command work in your Trace32?
Do me a favor - just stop at a breakpoint and type a.l (Analyzer.Log)
and see what happens.
PS Judging from your posts, there's a non-zero probability that we
work for the same company ;-)
xrando...@gmail.com
> On Apr 4, 2:53 am, xrandomhac...@gmail.com wrote:
>
> > On Apr 4, 12:30 am, "tum_" <atoumantsev_s...@mail.ru> wrote:
>
> Lucky you... (However, Lauterbach have a range of products, if you're
> lucky to have the full In-Circuit Emulator - then you just can't ask
> for more). Does the 'a.l' command work in your Trace32?
> Do me a favor - just stop at a breakpoint and type a.l (Analyzer.Log)
> and see what happens.
I'm replying this from home so no debuggers in sight, will tell you as
soon as possible.
> PS Judging from your posts, there's a non-zero probability that we
> work for the same company ;-)
Well my company has a holiday tomorrow (4/5) ... match that :)
tum_
No, it doesn't match ... yet, but I'd thought of holidays as country
specific rather than company specific. so, unless your company doesn't
have any representatives outside your country (which I reckon is US),
the probabilty remains != 0.
(The things that coincide are: ARM, Nucleus and Lauterbach/Trace32 -
used it for years but not with ARM-based devices...).
xrando...@gmail.com
<snip>
> > > Do me a favor - just stop at a breakpoint and type a.l (Analyzer.Log)
> > > and see what happens.
On typing a. it says command locked :'( The H/W has POWER DEBUG
written on it. CPU>Exception Control is also locked.
<snip>
> > Well my company has a holiday tomorrow (4/5) ... match that :)
>
> No, it doesn't match ... yet, but I'd thought of holidays as country
> specific rather than company specific. so, unless your company doesn't
> have any representatives outside your country (which I reckon is US),
> the probabilty remains != 0.
It isn't US :P
> (The things that coincide are: ARM, Nucleus and Lauterbach/Trace32 -
> used it for years but not with ARM-based devices...).
Well look at the bright side ... you are very much employable by the
company I work for :) only you'd have to relocate further east ;)
Cheers
tum_
> On Apr 5, 3:45 am, "tum_" <atoumantsev_s...@mail.ru> wrote:
>
> <snip>
>
> > > > Do me a favor - just stop at a breakpoint and type a.l (Analyzer.Log)
> > > > and see what happens.
>
> On typing a. it says command locked :'( The H/W has POWER DEBUG
> written on it. CPU>Exception Control is also locked.
All right then, you've got an In-Circuit Debugger, one of these
things:
http://www2.lauterbach.com/doc/bdm.pdf
[you can also find lots of info here: http://www.lauterbach.de]
I also have such a thing, which I use to debug one of our devices (the
one that doesn't generate exceptions).
But the "real thing" is this: http://www2.lauterbach.com/doc/ice.pdf
>
> <snip>
>
> > > Well my company has a holiday tomorrow (4/5) ... match that :)
>
> > No, it doesn't match ... yet, but I'd thought of holidays as country
> > specific rather than company specific. so, unless your company doesn't
> > have any representatives outside your country (which I reckon is US),
> > the probabilty remains != 0.
>
> It isn't US :P
Then I'm not a good detective. (Well, you write dates ('4/5' for April
5) in american way, you mentioned SSN - again US specific thing AFAIK
- you must be an american living outside of US ;) )
>
> Well look at the bright side ... you are very much employable by the
> company I work for :) only you'd have to relocate further east ;)
No more relocations, thanks ;) But you never know...
(and 'further east' - from where? do you know where I am?)