Page 2 of 2

Re: GCC Cross Compiler Tutorial Suggestions

Posted: Tue Sep 02, 2014 4:49 pm
by Wajideu
This is just a new trick I discovered that some people might find useful, which isn't particularly limited to building the gcc, but it is very interesting.


If you take an object file and dump the de-mangled symbols from it with nm

Code: Select all

nm -C obj.exe >> obj.txt
you'll end up with a list of symbols like:

Code: Select all

00403004 D mystring
You can actually use those values in your application:

Code: Select all

#define ptr2val(type, ptr) *((type*)(ptr))

printf(ptr2val(char *, 0x00403004));
I'm thinking about writing a branch of gettext that adds new instructions:

Code: Select all

ptrid untranslatedVarName
ptrval translatedVarName
then extracts the symbols from the applications object files. This would largely benefit applications on embedded systems where a file system isn't available, or where having file names embedded into the application takes too much space.

Re: GCC Cross Compiler Tutorial Suggestions

Posted: Tue Sep 02, 2014 5:40 pm
by sortie
wat.

Re: GCC Cross Compiler Tutorial Suggestions

Posted: Tue Sep 02, 2014 5:57 pm
by GhostlyDeath
DaemonR wrote:...I'm thinking about writing a branch of gettext that adds new instructions:

Code: Select all

ptrid untranslatedVarName
ptrval translatedVarName
then extracts the symbols from the applications object files. This would largely benefit applications on embedded systems where a file system isn't available, or where having file names embedded into the application takes too much space.
Most embedded images once deployed will have extensive debug maps and symbols created which can be used with a debugger.

Re: GCC Cross Compiler Tutorial Suggestions

Posted: Tue Sep 02, 2014 7:40 pm
by Wajideu
GhostlyDeath wrote:Most embedded images once deployed will have extensive debug maps and symbols created which can be used with a debugger.
It's not always the case though. The system I had in my mind while thinking about this only has about 4MiB of ram and 64MiB of rom. Making an application with a decent amount of content requires stripping the symbols and using overlays. Gettext just isn't a reliable method of localization for it.

Re: DaemonR's assorted tricks

Posted: Wed Sep 03, 2014 7:41 pm
by Wajideu
This is just something I realized here recently, if you're using MinGW on Windows, DO NOT use the gui installer assistant!!

The MinGW installer sets up the package like:

Code: Select all

MinGW = C:/MinGW
MSYS = C:/MinGW/msys/1.0
But this is @$$-backwards. All of the shell scripts are configured to work like

Code: Select all

MinGW = C:/MSYS/mingw
MSYS=C:/MSYS
If you don't set it up this way you'll be thrown for a loop when you try to set up a more complex autotools project with gettext or custom m4 scripts because nearly every single script will be pointing at the wrong directory (including /etc/profile, which is why many users have to manually add C:/MinGW/bin to their environment path)


Instead, do it manually by following the directions on this page (MSYS) and this page (MinGW).

(Note: MSYS Core 1.0.11 is a misdirected link, it's actually here)

--------

Some extra installation notes for when installing MinGW libs from the SourceForge repository:
  • The gettext, automake, autoconf, and libtool binaries you want to install are in the MinGW/Base and MinGW/Extension directories. These you'll want to install into your /mingw directory.
  • You'll need the gettext dev package for gettextize
  • You'll want to install all versions of automake and autoconf and their wrappers
  • The bison and flex you want are in MSYS/Extensions. These you'll want to install into your / directory. You may want wget here as well.