This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: CORE_ADDR representation
>>>>> "Daniel" == Daniel Jacobowitz <dan@codesourcery.com> writes:
Mark> Perhaps we should introduce a function to "normalize" addresses (mask
Mark> off high-bits or sign extend) that we call in places that need it?
Mark> It'd be a no-op for a N-bit debugger debugging an N-bit target, so
Mark> you'd be able to call it unconditionally. That should clear away
Mark> quite a bit of clutter.
Daniel> That does sound better than the status quo. I worry that we'll have
Daniel> otherwise the same trouble with figuring out places that 'need' it...
Daniel> Hmm. I wonder if we could use a static analysis tool for this. It
Daniel> sounds like a classic example of a static problem.
The appended finds all uses of "+" on a CORE_ADDR. Well... it finds
"all" uses modulo whatever little issues coccinelle has, I didn't mess
around trying to make it look into macros.
I ran it like:
cd src/gdb
spatch -sp_file coreaddr.cocci -dir .
... and got 1071 hits.
On Fedora you can get the tool with "yum install coccinelle", I assume
other distros are similar. Also it is here:
http://coccinelle.lip6.fr/
I'm not sure if this was what you're really looking for, but it isn't
too hard to modify this script to look for other things.
The problem with doing static analysis is that you have to redo it
pretty frequently. While moving to a struct CORE_ADDR would result in
more verbose code (which is definitely bad, don't get me wrong), it does
have the benefit that an attempt to do arithmetic on it results in a
compiler error. This in turns means it is simpler to review the
resulting patches.
Tom
@ coreaddr
@
CORE_ADDR x;
expression y;
position p_1;
@@
x @p_1 + y
@
script:python @ loc_1 << coreaddr.p_1;
@@
print "%s:%s:%s: CORE_ADDR + operation" % (loc_1[0].file, loc_1[0].line, loc_1[0].column)