Go to Post Two students with no clue but enough dedication to work on something is always better than one expert who doesn't care enough not to leaveit until the last day. - Matt Krass [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rating: Thread Rating: 6 votes, 5.00 average. Display Modes
Prev Previous Post   Next Post Next
  #20   Spotlight this post!  
Unread 08-01-2013, 19:47
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Quote:
Originally Posted by CodeYeti View Post
Hey there it's me again! I just noticed something that may be odd, but keep in mind that the concept of "stripping" syms is new to me outside of this problem. I'm going to try some simple testing of code on our new hardware tonight, and I wanted to make sure that my binary was compiling for the correct architecture and whatnot. A `file bin/FRC_UserProgram.out' yielded the following output.
Code:
bin/FRC_UserProgram.out: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (SYSV), not stripped
I noticed that it says it's "not stripped". Does that mean that maybe when I try this on hardware I will get conflicts with the kernel? Is my stripping still not working?

Thanks in advance for the help.
Though stripping the symbols was my original idea, I decided to instead localize the symbols. That way the symbols would still be internally visible in case we ever get a debugger to actually *work*, but they would not conflict with the external symbols for the kernel's libgcc/stdc++/supc++. So the file is correct, it is not stripped. If you look at the stripsyms script what it does is loads the symbols from these libraries into a file and then has objdump look for instances of those symbols in the executable and localize them. I figured this was as close as optimal to an ideal solution.

ALSO, w/r/t why 3.4?

Basically newer versions of GCC have issues on windows where it is very difficult to get any sort of cross compiler set up. I think MinGW doesn't support any cross compiler >3.4.5. So by moving to linux (it might also be an interesting experiment to try this toolchain in cygwin) you also gain the ability to tap the last 10 years of innovation from the GNU project
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 09:59.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi