[M3devel] m3gdb/AMD64_LINUX, a little progress

[Jay]

Right, definitely good to make the invasive changes minimal.
Our diffs within gcc are quite small I found.
Almost everything is adding the file parse.c
 
 
CVS is supposed to help here, three way merge and all that, but
there is only so much it can do.
 
 
 - Jay


----------------------------------------
> Date: Fri, 26 Jun 2009 21:40:12 -0500
> From: rodney.m.bates at cox.net
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3gdb/AMD64_LINUX, a little progress
>
> Jay wrote:
>> You should try using cvs import to upgrade to a newer version, of the
>> entire gdb tree (well, maybe prune it -- testsuites, sim, cpu, intl,
>> etc..)
>> I personally have never done this -- only recently imported the first
>> version of stuff but haven't yet updated anything.
> There is a _lot_ of merging work to get the m3gdb changes into a newer gdb
> base, including a lot of manual cleanup. I've done it. More than
> once. I plan to
> do it again, real soon now, but this was a reckless attempt at something
> quick
> and dirty. Also, there is a newest gdb release 6/9 forthcoming soon, and I
> think it would be nice to wait for it.
>
> I have been gradually pulling m3 support code out of gdb source files
> and putting
> into m3-*.c files, with only calls, etc in the original gdb source.
> This should help
> a bit for the next time around. But there is always lots of rework in
> a later gdb
> that requires corresponding rework to m3gdb. Things go away or are
> replaced
> by something redesigned, and it takes work to figure out what the
> replacement is
> and how to use it.
>>
>> - Jay
>>
>>
>>> Date: Wed, 24 Jun 2009 11:18:30 -0500
>>> From: rodney.m.bates at cox.net
>>> To: m3devel at elegosoft.com
>>> Subject: [M3devel] m3gdb/AMD64_LINUX, a little progress
>>>
>>> I have tracked down the problems I have seen with m3gdb on
>>> AMD64_LINUX not recognizing object formats to a new section
>>> type SHT_GNU_HASH, (and named .gnu.hash), which is present
>>> in recent M3-compiled code. It appears to be handled by
>>> the more recent binutils that comes in gdb 6.8, but it is
>>> not handled by the binutils in gdb 6.4, from which m3gdb is
>>> derived.
>>>
>>> I briefly tried a naive substitution of the new binutils
>>> (directory 'bfd') into m3gdb, but some things have moved
>>> around and there are build problems finding them. I will
>>> work on this more when I get some time.
>>>
>>> Rodney Bates
>