From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: How to add core addresses (or LM_ADDR problems revisited) Date: Wed, 03 Oct 2001 01:03:00 -0000 Message-id: <1011003080243.ZM22427@ocotillo.lan> References: <1011003013114.ZM22147@ocotillo.lan> <3BBA7ED7.50205@cygnus.com> X-SW-Source: 2001-10/msg00043.html 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