search

foss-for-synopsys-dwc-arc-processors / binutils-gdb

A mirror of the upstream binutils-gdb repository for ARC specific work
GNU General Public License v2.0
13 stars 10 forks source link

[GDB] ARC-specific changes (CFI compatibility with MWDT) causes other target builds to fail #61

Closed abrodkin closed 3 years ago

abrodkin commented 3 years ago

As of today our changes for MWDT compatibility (generic code changes & ARC-only changes) if applied won't allow to use the same sources to be built for any architecture but ARC. The following error appears:

[ERROR]   .../.build/aarch64-unknown-linux-gnu/src/gdb/gdb/aarch64-tdep.c:3563:44: error: invalid conversion from 'bool (*)(gdbarch*, gdb_byte, dwarf2_frame_state*) {aka bool (*)(gdbarch*, unsigned char, dwarf2_frame_state*)}' to 'bool (*)(gdbarch*, gdb_byte, dwarf2_frame_state*, const gdb_byte**, const gdb_byte*) {aka bool (*)(gdbarch*, unsigned char, dwarf2_frame_state*, const unsigned char**, const unsigned char*)}' [-fpermissive]
[ERROR]    .../.build/aarch64-unknown-linux-gnu/src/gdb/gdb/gdbarch.h:872:13: error:   initializing argument 2 of 'void set_gdbarch_execute_dwarf_cfa_vendor_op(gdbarch*, bool (*)(gdbarch*, gdb_byte, dwarf2_frame_state*, const gdb_byte**, const gdb_byte*))' [-fpermissive]

That means we cannot have that patch set in upstream projects (like Crosstool-NG) even as an off-the-tree patches. But if we wrap changes we need in ifdefs that will allow to use these patches much more relaxed.

For example I managed to post all our GDB backports to CT-NG (see https://github.com/crosstool-ng/crosstool-ng/commit/8099a7475083e04429990c53cd490cda9eb63d68, via https://github.com/crosstool-ng/crosstool-ng/pull/1595) but had to exclude aforementioned patches.

Well, ideally it would be good to upstream it, but that will obviously require us to do much more changes.

shahab-vahedi commented 3 years ago

...it would be good to upstream it, but that will obviously require us to do much more changes.

For the record, that patch is not acceptable upstream. No matter how much effort is put there. In that sense, the real effort must be put on making MWDT produce more standard DWARF data.

Regarding the ifdefs, we're on the same page.

temap commented 3 years ago

@abrodkin merged, thanks.

cupertinomiranda commented 3 years ago

What was the resolution here ? Where and what got merged ?

I guess we should start tagging the issues as being from GDB, LD or AS as well, as it would make it much more easy understand context.

abrodkin commented 3 years ago

@cupertinomiranda there's no resolution yet. @shahab-vahedi is going to wrap our non-upstreamable changes into ifdefs to make them non-visible to other arches. And I guess @temap really meant to close after merge this PR for our CT-NG: https://github.com/foss-for-synopsys-dwc-arc-processors/crosstool-ng/pull/1.

As for labeling - it's a good idea. We do it in toolchain issues but here we never needed those and now maybe it's time to add it here.

shahab-vahedi commented 3 years ago

The obvious approach here would be to use #if guards. However, this will not fully work, because one can configure GDB as such to support multiple targets, e.g. configure --target=arc-elf32 --enable-targets=arm-elf32,sparcs-elf32 ....

According to @claziss probably the ARCH_arc macro can be used for this hack.

abrodkin commented 3 years ago

@shahab-vahedi I guess that case of adding multiple targets while may exist, but I'm not aware of such cases, people just build multiple GDB versions. That said the most important would be to separate ARC target from all the rest.

shahab-vahedi commented 3 years ago

You know CrossNG better than I. In GDB development, it happens all the time to make sure that a change does not break other targets. In the end, they run tests for that all-purpose gdb.

shahab-vahedi commented 3 years ago

The latest patch updates the aarch64-tdep.c file as well. So the build should go OK.