Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linking fails with Arm Toolchain 8-2019-q3-update Linux 64-bit #153

Closed
aderic6 opened this issue Jul 28, 2019 · 6 comments

Comments

@aderic6
Copy link

commented Jul 28, 2019

Expected Behavior:

Ran prosv5 make all and expected to compile into hot and cold image.

Actual Behavior:

Compiling of source files works until attempting to link with libpros and libokapi. The same set of files compile with the previous 2018 December Arm Toolchain.

Steps to reproduce:

  1. Download the new Linux 64-bit toolchain from Arm Developers
  2. Extract and move the folder to /opt/arm-gcc-none-eabi/ replacing old toolchain
  3. Export to PATH using ~/.profile and sourcing the file.
  4. Make a new PROS project with conductor.
  5. Run prosv5 make in project directory (both with and without hot and cold linking yields the same error).

System information:

Manjaro 18.0.4 (4.19.60-1-MANJARO)

PROS Version: pros, version 3.1.4

Additional Information

Ran on a clean install with no other conflicting packages and whereis points to the extracted toolchain. The linking failure occurs with the default PROS project source files too.
Python 3.7.3 used and PROS installed using pip3 without --user flag.

Screenshots/Output Dumps/Stack Traces

image

@HotelCalifornia

This comment has been minimized.

Copy link
Member

commented Jul 28, 2019

Thanks for the report, I was worried something like this would happen when I saw Arm updated the official toolchain. Will need to investigate to see what's wrong.

@Octogonapus

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2019

Use version 8.2.1 or lower.

@HotelCalifornia

This comment has been minimized.

Copy link
Member

commented Jul 28, 2019

Use version 8.2.1 or lower.

That was mentioned as a workaround in the OP. We still need to figure out what's wrong.

@Octogonapus

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2019

That was mentioned as a workaround in the OP

My bad, I am so used to replying to these __sync_synchronize issues...

@HotelCalifornia HotelCalifornia transferred this issue from purduesigbots/pros-cli Jul 28, 2019

@HotelCalifornia

This comment has been minimized.

Copy link
Member

commented Jul 28, 2019

Done some looking, and it seems like you can just stub it in the interim. It also seems like we might be able to solve this more effectively by playing with the arch flags-- I don't like just adding a stub as a solution unless I can say for sure that we don't need the symbol to do anything, especially if we want to get pthread working.

@HotelCalifornia

This comment has been minimized.

Copy link
Member

commented Aug 8, 2019

ok, done some more looking and found this thread which suggests defining the stub like so:

void __sync_synchronize(void) {
    __sync_synchronize();
}

because

... some of the libstdc++ librararies in [arm-none-eabi] are broken because they try and call a function named __sync_synchronize(), instead of have being compiled using the built-it of that name.

and

this looks like an infinite recursion, but looking at the generated assembler shows that the compiler did generate a function named __sync_synchronize which contains the memory barrier instruction

I added this to the newlib_stubs.c file, which fixed the linking error. Checking the cold package with arm-none-eabi-objdump reveals that

0383717c <__sync_synchronize>:                                                                                                                                                                                                                 
  383717c:       f57ff05b        dmb     ish                                                                                                                                                                                                    
  3837180:       e12fff1e        bx      lr

where dmb ish is the correct memory barrier instruction. Will open a PR shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.