This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: How to add core addresses (or LM_ADDR problems revisited)


On Oct 2, 10:58pm, Andrew Cagney wrote:

> Looking at the proposal:
> 
> > CORE_ADDR
> > core_addr_add (CORE_ADDR addr1, CORE_ADDR addr2)
> 
> Thinking of C, I suspect two operators are required:
> 
> CORE_ADDR core_addr_add (CORE_ADDR addr, LONGEST offset);
> LONGEST core_addr_sub (CORE_ADDR a1, CORE_ADDR a2);

First, I'll note that I've already implemented core_addr_sub(), but it
wasn't different enough from core_addr_add() to merit being included
in my earlier post.  The version that I implemented returns a
CORE_ADDR though.

Second, regarding the types, I (initially) also thought that an offset
should be represented as some other type (than a CORE_ADDR), but in
the process of converting existing GDB code to use core_addr_add() and
core_addr_sub(), I've found that the type of the offset is almost
always a CORE_ADDR.  (Maybe even always.) I suppose it's possible that
we simply have this detail wrong, but I'm reluctant to change it at
the moment.  (It's rather pervasive...)

> Don't forget that the MIPS expects sign extension so that will need to 
> be handled from day one.  I suspect core_addr_add() and core_addr_sub() 
> are the things to multi-arch.

Okay, I'll take a look at this.

> Any way, yes, I think this is long overdue!

Cool.  I'll continue work on it and send out a patch once I've
figured out what to do about MIPS.  My initial patch will handle
all of the expressions involving ANOFFSET() or expressions which
get their value from an ANOFFSET assignment.  Obviously, there are
a lot of other expressions involving CORE_ADDR which will eventually
need to be converted, but the ANOFFSET related ones are a good
starting point since it fixes the LM_ADDR problem.

> PS: The comment should suggest gdbarch_data() not gdbarch_swap() :-)

I considered this, but I was trying to avoid the function call needed
to fetch the data!  However, I'll revise the comment so that it
mentions gdbarch_data() as well.  I'll also discuss the pros and cons
of each in this setting.

Thanks for your feedback.

Kevin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]