Experimental Support for Microblaze 64-bit Architecture - binutils and gdb

[Michael Eager]

On 7/12/24 07:13, Simon Marchi wrote:
> On 7/12/24 1:03 AM, Gopi Kumar Bulusu wrote:

Hi Gopi -- good to hear from you!

>>
>> namaskaram
>>
>> Here is my thinking --
>>
>> As  gas/ld/rob (rest of binutils) are producers of elf and gdb is a consumer adding experimental microblaze 64-bit support patches  in the former (bfd)  and not latter will mean gdb built from the exact same  binutils-gdb code base won't be able to process the mb64 binaries and any one planning to run/debug the binaries with gdb will not be able to do so.  Also the reason for starting with binutils-gdb before contributing
>> patches to gcc.
> 
> If you first add support for 64-bit to gas/ld (and even gcc), I presume
> that debugging 32-bit Microblaze programs with gdb will keep working.
> Debugging 64-bit Microblaze programs with gdb will not work (yet), but
> that is not a regression.
> 
> Anyhow, given that binutils and gdb are in the same repo, it would be
> fine to send changes to binutils and gdb in the same patch series (but
> in properly separated patches).  binutils maintainer will approve
> binutils patches, and gdb maintainers will approve gdb patches.

I'd prefer to see separate patches for binutils and gdb.  That can be a 
series of patches, as Simon suggests, not one combined patch.

There is no problem with adding new arch support to binutils, making 
sure that it works correctly, then later adding support in gdb.  At each 
step, there should be no regressions.

>> Also, as part of this effort I had to merge bintutils binutils-gdb and
>> gdb binutils-gdb patches for the target from Xilinx git that have over
>> the years digressed. I think It will be a good idea to keep them in
>> sync as part of this effort.

A number of patches to binutils support for Microblaze were submitted 
last year.  Make sure that you are not duplicating that effort.

Separate out bug fix patches and submit them independently.  Each bug 
fix patch should include a test case.  A Big Wad Of Stuff patch 
addressing multiple bugs and new arch support is not very welcome.

> Having everything upstream is the best way to avoid diverging and
> staying stuck with an old version.

Agreed.

> Thanks a lot for working on this.

Likewise.

--
Michael Eager