Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

has anybody tried gcc-4.1.0 for generating mod files ?

I have not, but I've been goofing around trying to get codesourcery's 3.4.4 (2005-q3-2) toolchain to go and I suspect the problems may be similar.
The bottleneck I am finding is BREWelf2mod only understands a small set of ELF relocations (PLT32, PC24, ABS32 and, in the 1.0.1 tools version, PC22) and as the ELF EABI has evolved over the years after 2003, the GNU compilers are generating different relocations and giving the old ones new names. (THM_PC22 == THM_CALL) and deprecating the old ones.
Now, BREWelf2mod is, charitably, "weak" as tools go. Secretly it exec()s GNU objdump to get the list of rellocations -- you can specifiy what .exe to use on the command line as an optional 3rd parameter. But if the ASCII list of rellocation names contains strings it does not recognize (R_ARM_THM_CALL, say) , it will crap out with an "unknown rellocation type" error. (I just opened the BREWelf2mod.exe in my editor to see what R_ARM_XXX strings it contains -- that's how I know what relocs it supports -- assuming it does a strcmp() somewhere.)
So, my problem is, I can't find any incantation that generates a GNU ARM ELF file that only contains allocations BREWelf2mod recognizes. Even if I run an old (gnude) objdump against my new (sourcery) ELF exe to get old names for new relocs. Even if I just do ARM and not thumb code, I get R_ARM_CALL (unrecognized) and R_ARM_ABS32 (recognized) if I use the sourcery objdump, and R_ARM_RREL32 (unrecognized) R_ARM_ABS32 (recognized) if I use the gnude objdump (on the same 3.4.4 sourcery ARM ELF exe).
I'm dong C++ in Win32 (not running under cygwin) FWIW.
I'm surprised no one has cranked out a replacement for BREWelf2mod as it does not seem like it would be that hard. "All" the program has to do extract the text and reloc data, cook the reloc table and add the startup assembler to the resulting output file just before the AEEMod_Load entry. A new utility could also 1) have a version number; 2) use good programming to provide decent error messages and handle program identifiers of any length -- someone here mentioned they thought BREWelf2mod was using maybe a 255 byte static buffer for objdump output lines and it pee'd on the output if this was exceeded -- seems likely, or, even better, don't use objdump at all: just memory map the ELF file and parse/transform it directly; 3) support uninitialized global variables by preserving the .bss section -- a modified version of the startup code could even set this to zero -- that might make the ADS guys jealous!
Qualcomm would be smart to just release the source to e2m with caveats that it may not be supported in BREW 4, etc. and give folks blessing to wail on it. They could even forbid tinkering with the startup prgram -- since that is where a bunch of possible features could be implemented (compression, DRM/licensing, global vars, static objects) -- and where incompatibilites would be introduced.
There is a development tools startup company idea here for someone to do VStudio 2005 integration and custom mod generation like this if QC won't do it. My (big) company has paid me many thousands of dollars by now to investigate what seems a dead-end at the moment -- we, and I suspect others, would much rather write a check to some hot-shot tools group and have the problem solved immediately -- and it would still cost less than ADS/RVDS.
And yes, I do have ADS/RVDS here and I am going to switch over to it now. Too bad QC looses all the energy of the open source development community by not supporting their tools better. This seems strange to me since those little developers seem to be the kind of barnacles QC wants to attach to the BREW mothership and begin tithing.
End rant.
-- Ward

I have not, but I've been goofing around trying to get codesourcery's 3.4.4 (2005-q3-2) toolchain to go and I suspect the problems may be similar.
The bottleneck I am finding is BREWelf2mod only understands a small set of ELF relocations (PLT32, PC24, ABS32 and, in the 1.0.1 tools version, PC22) and as the ELF EABI has evolved over the years after 2003, the GNU compilers are generating different relocations and giving the old ones new names. (THM_PC22 == THM_CALL) and deprecating the old ones.
Now, BREWelf2mod is, charitably, "weak" as tools go. Secretly it exec()s GNU objdump to get the list of rellocations -- you can specifiy what .exe to use on the command line as an optional 3rd parameter. But if the ASCII list of rellocation names contains strings it does not recognize (R_ARM_THM_CALL, say) , it will crap out with an "unknown rellocation type" error. (I just opened the BREWelf2mod.exe in my editor to see what R_ARM_XXX strings it contains -- that's how I know what relocs it supports -- assuming it does a strcmp() somewhere.)
So, my problem is, I can't find any incantation that generates a GNU ARM ELF file that only contains allocations BREWelf2mod recognizes. Even if I run an old (gnude) objdump against my new (sourcery) ELF exe to get old names for new relocs. Even if I just do ARM and not thumb code, I get R_ARM_CALL (unrecognized) and R_ARM_ABS32 (recognized) if I use the sourcery objdump, and R_ARM_RREL32 (unrecognized) R_ARM_ABS32 (recognized) if I use the gnude objdump (on the same 3.4.4 sourcery ARM ELF exe).
I'm dong C++ in Win32 (not running under cygwin) FWIW.
I'm surprised no one has cranked out a replacement for BREWelf2mod as it does not seem like it would be that hard. "All" the program has to do extract the text and reloc data, cook the reloc table and add the startup assembler to the resulting output file just before the AEEMod_Load entry. A new utility could also 1) have a version number; 2) use good programming to provide decent error messages and handle program identifiers of any length -- someone here mentioned they thought BREWelf2mod was using maybe a 255 byte static buffer for objdump output lines and it pee'd on the output if this was exceeded -- seems likely, or, even better, don't use objdump at all: just memory map the ELF file and parse/transform it directly; 3) support uninitialized global variables by preserving the .bss section -- a modified version of the startup code could even set this to zero -- that might make the ADS guys jealous!
Qualcomm would be smart to just release the source to e2m with caveats that it may not be supported in BREW 4, etc. and give folks blessing to wail on it. They could even forbid tinkering with the startup prgram -- since that is where a bunch of possible features could be implemented (compression, DRM/licensing, global vars, static objects) -- and where incompatibilites would be introduced.
There is a development tools startup company idea here for someone to do VStudio 2005 integration and custom mod generation like this if QC won't do it. My (big) company has paid me many thousands of dollars by now to investigate what seems a dead-end at the moment -- we, and I suspect others, would much rather write a check to some hot-shot tools group and have the problem solved immediately -- and it would still cost less than ADS/RVDS.
And yes, I do have ADS/RVDS here and I am going to switch over to it now. Too bad QC looses all the energy of the open source development community by not supporting their tools better. This seems strange to me since those little developers seem to be the kind of barnacles QC wants to attach to the BREW mothership and begin tithing.
End rant.
-- Ward

I just used WinARM GCC 4.1.0 to compile my enormous app. It runs on the phone if I compile it for ARM (not thumb). This jibes with some info I got by private e-mail.
For some reason, the mod is coming out twice as large as the ELF file. This is the first time I have seen this and this is the largest mod file I have made in all my experiments with different compilers so far. Perhaps something is set wrong, perhaps putting each function in a separate section makes a ton of relocations.
If I compile for thumb, the output is a little smaller, but I can only get it through BREWelf2mod if I pass it the gnude version of objdump. This causes the THM_CALL relocations to be listed as (old) PC24 relocations.
Howver, since the thumb module blows up when I try to run it, I suppose this mapping may not be correct! (And yes, I compiled modgen and appgen in ARM mode and AEEMod_Load() is first.)
COMPILE:
d:\winARM\bin\arm-elf-g++.exe -fno-builtin -fno-exceptions -fno-unwind-tables -fno-rtti -ffunction-sections
-DDEBUG -DDYNAMIC_APP -I -o -c
LINK:
d:\winARM\bin\arm-elf-ld.exe -Ttext 0 --no-warn-mismatch -Map --cref --emit-relocs -entry=AEEMod_Load
-L -zcombreloc -o "ARM GNU Debug\AEEModGen.o" -( -l gcc -)
Hmmm. Seem to have forgotten my ARM7T switch...back to drawing board....

I just used WinARM GCC 4.1.0 to compile my enormous app. It runs on the phone if I compile it for ARM (not thumb). This jibes with some info I got by private e-mail.
For some reason, the mod is coming out twice as large as the ELF file. This is the first time I have seen this and this is the largest mod file I have made in all my experiments with different compilers so far. Perhaps something is set wrong, perhaps putting each function in a separate section makes a ton of relocations.
If I compile for thumb, the output is a little smaller, but I can only get it through BREWelf2mod if I pass it the gnude version of objdump. This causes the THM_CALL relocations to be listed as (old) PC24 relocations.
Howver, since the thumb module blows up when I try to run it, I suppose this mapping may not be correct! (And yes, I compiled modgen and appgen in ARM mode and AEEMod_Load() is first.)
COMPILE:
d:\winARM\bin\arm-elf-g++.exe -fno-builtin -fno-exceptions -fno-unwind-tables -fno-rtti -ffunction-sections
-DDEBUG -DDYNAMIC_APP -I -o -c
LINK:
d:\winARM\bin\arm-elf-ld.exe -Ttext 0 --no-warn-mismatch -Map --cref --emit-relocs -entry=AEEMod_Load
-L -zcombreloc -o "ARM GNU Debug\AEEModGen.o" -( -l gcc -)
Hmmm. Seem to have forgotten my ARM7T switch...back to drawing board....

Ooops. Cut and paste error, I did have the following on the compile line too:
-mlittle-endian -mcpu=arm7tdmi -mthumb-interwork -mapcs-frame -Os

Ooops. Cut and paste error, I did have the following on the compile line too:
-mlittle-endian -mcpu=arm7tdmi -mthumb-interwork -mapcs-frame -Os

wardw wrote:For some reason, the mod is coming out twice as large as the ELF file.
After your help getting .elf generation working, I got the e2m tool hooked up. If you're seeing only 2x the size, then you're lucky.
I compiled my app twice; once with -O0 and once with -O2.
For no optimization:
Total size of objects: 448k
Size of .elf: 428k
Size of .mod: 3.6M!
With -O2
Total size of objects: 307k
Size of .elf: 297k
Size of .mod: 3.6M again!
Now, the size of my .o files and the size of the .elf file seem to make sense. Right now we're using the Officially Licensed Compiler and it's making .mod files around 300k, so at first blush everything looks good.
Except for the size of the .mod. I mean, 3.6 megabytes? What the heck?
We were hoping to move developers to being able to compile locally (instead of using a server set up with our only copy of the Realview Compilation Tools for Brew(tm) software). But if e2m will only make .mod files that size, then it almost seems like the tool's not designed to be used at all!
Any ideas on how to put the .mod file on a severe diet?

wardw wrote:For some reason, the mod is coming out twice as large as the ELF file.
After your help getting .elf generation working, I got the e2m tool hooked up. If you're seeing only 2x the size, then you're lucky.
I compiled my app twice; once with -O0 and once with -O2.
For no optimization:
Total size of objects: 448k
Size of .elf: 428k
Size of .mod: 3.6M!
With -O2
Total size of objects: 307k
Size of .elf: 297k
Size of .mod: 3.6M again!
Now, the size of my .o files and the size of the .elf file seem to make sense. Right now we're using the Officially Licensed Compiler and it's making .mod files around 300k, so at first blush everything looks good.
Except for the size of the .mod. I mean, 3.6 megabytes? What the heck?
We were hoping to move developers to being able to compile locally (instead of using a server set up with our only copy of the Realview Compilation Tools for Brew(tm) software). But if e2m will only make .mod files that size, then it almost seems like the tool's not designed to be used at all!
Any ideas on how to put the .mod file on a severe diet?

I finally made a test program last night instead of my "real" app -- in order to try and isolate this. My 37,943 byte ELF becomes a 3,933,121 byte mod.
We are in the same boat you are and are persuing this for many of the same reasons -- plus, I have a lot of legacy C++ that I would have to make modifications to satisfy the -ropi requirement of ADS.
I will be comparing the ELF section headers generated by gnude (3.x) against the ones generated by winarm (4.x) today to see if anything leaps out. At first glance, nothing in the winarm ELF looks unusual...
I am this close to writing my own elf2mod so I can at least debug these things -- but not sure how my boss would feel about that!

I finally made a test program last night instead of my "real" app -- in order to try and isolate this. My 37,943 byte ELF becomes a 3,933,121 byte mod.
We are in the same boat you are and are persuing this for many of the same reasons -- plus, I have a lot of legacy C++ that I would have to make modifications to satisfy the -ropi requirement of ADS.
I will be comparing the ELF section headers generated by gnude (3.x) against the ones generated by winarm (4.x) today to see if anything leaps out. At first glance, nothing in the winarm ELF looks unusual...
I am this close to writing my own elf2mod so I can at least debug these things -- but not sure how my boss would feel about that!

wardw wrote:I am this close to writing my own elf2mod so I can at least debug these things -- but not sure how my boss would feel about that!
Well, maybe we have an opportunity to pool our resources here. This is something I'd be interested in working on, but I don't have a lot of compilers experience (course, if you wanted a high-performance search algorithm, I'm your man, but you don't, so I'm not). Certainly my company would benefit from this, depending on the cost of time.
I've noticed in some other threads that the .elf -> .mod file size explosion seems to be very inconsistent (http://brewforums.qualcomm.com/showthread.php?t=10989, [url]http://brewforums.qualcomm.com/showthread.php?t=2033)[/url]. I'm starting to wonder (especially after yours just went up around 100x) if we're not getting a ton of stuff getting linked in statically for some reason... maybe entire libraries. I know that nm can look at .o, .a, and .elf files (amongst others) but it doesn't seem to recognize .mod files, so I can't see what it's got inside it.
Maybe we can talk more about this off-line, if you wish. My e-mail is thomash at airg com.

wardw wrote:I am this close to writing my own elf2mod so I can at least debug these things -- but not sure how my boss would feel about that!
Well, maybe we have an opportunity to pool our resources here. This is something I'd be interested in working on, but I don't have a lot of compilers experience (course, if you wanted a high-performance search algorithm, I'm your man, but you don't, so I'm not). Certainly my company would benefit from this, depending on the cost of time.
I've noticed in some other threads that the .elf -> .mod file size explosion seems to be very inconsistent (http://brewforums.qualcomm.com/showthread.php?t=10989, [url]http://brewforums.qualcomm.com/showthread.php?t=2033)[/url]. I'm starting to wonder (especially after yours just went up around 100x) if we're not getting a ton of stuff getting linked in statically for some reason... maybe entire libraries. I know that nm can look at .o, .a, and .elf files (amongst others) but it doesn't seem to recognize .mod files, so I can't see what it's got inside it.
Maybe we can talk more about this off-line, if you wish. My e-mail is thomash at airg com.

I can tell you that most of the space bloat in the MOD file is zeroes. For some reason, BREWelf2mod thinks it has to put the table of rellocation fixups WAY up high in the file.
So:
.text <---- 3MB+ of zeros --> relocation fixups | few more zeroes
Something about the 4.x scheme is confusing it about the section sizes -- I guess the size of the code in the .text section specifically. (BTW, this occurs even if I use the gnude ".xc" linker script. So at this point I don't think section layout is an issue, but...)

I can tell you that most of the space bloat in the MOD file is zeroes. For some reason, BREWelf2mod thinks it has to put the table of rellocation fixups WAY up high in the file.
So:
.text <---- 3MB+ of zeros --> relocation fixups | few more zeroes
Something about the 4.x scheme is confusing it about the section sizes -- I guess the size of the code in the .text section specifically. (BTW, this occurs even if I use the gnude ".xc" linker script. So at this point I don't think section layout is an issue, but...)

Followups to two things you posted:
wardw wrote:The bottleneck I am finding is BREWelf2mod only understands a small set of ELF relocations (PLT32, PC24, ABS32 and, in the 1.0.1 tools version, PC22) and as the ELF EABI has evolved over the years after 2003, the GNU compilers are generating different relocations and giving the old ones new names. (THM_PC22 == THM_CALL) and deprecating the old ones.
Now, BREWelf2mod is, charitably, "weak" as tools go. Secretly it exec()s GNU objdump to get the list of rellocations -- you can specifiy what .exe to use on the command line as an optional 3rd parameter. But if the ASCII list of rellocation names contains strings it does not recognize (R_ARM_THM_CALL, say) , it will crap out with an "unknown rellocation type" error. (I just opened the BREWelf2mod.exe in my editor to see what R_ARM_XXX strings it contains -- that's how I know what relocs it supports -- assuming it does a strcmp() somewhere.)
So, my problem is, I can't find any incantation that generates a GNU ARM ELF file that only contains allocations BREWelf2mod recognizes. Even if I run an old (gnude) objdump against my new (sourcery) ELF exe to get old names for new relocs. Even if I just do ARM and not thumb code, I get R_ARM_CALL (unrecognized) and R_ARM_ABS32 (recognized) if I use the sourcery objdump, and R_ARM_RREL32 (unrecognized) R_ARM_ABS32 (recognized) if I use the gnude objdump (on the same 3.4.4 sourcery ARM ELF exe).
Since we can specify the objdump to execute, could we instead specify a wrapper executable, that could take the output from objdump and just convert it into whatever e2m expects?
wardw wrote:I can tell you that most of the space bloat in the MOD file is zeroes. For some reason, BREWelf2mod thinks it has to put the table of rellocation fixups WAY up high in the file.
So:
.text <---- 3MB+ of zeros --> relocation fixups | few more zeroes
Something about the 4.x scheme is confusing it about the section sizes -- I guess the size of the code in the .text section specifically. (BTW, this occurs even if I use the gnude ".xc" linker script. So at this point I don't think section layout is an issue, but...)
Could we just prune all the zeros padding? Would that also require modifying the relocation fixups, at least what stuff is addressing? Does the .mod contain a header that shows its filesize, and/or a hashvalue, to prevent tampering?

Followups to two things you posted:
wardw wrote:The bottleneck I am finding is BREWelf2mod only understands a small set of ELF relocations (PLT32, PC24, ABS32 and, in the 1.0.1 tools version, PC22) and as the ELF EABI has evolved over the years after 2003, the GNU compilers are generating different relocations and giving the old ones new names. (THM_PC22 == THM_CALL) and deprecating the old ones.
Now, BREWelf2mod is, charitably, "weak" as tools go. Secretly it exec()s GNU objdump to get the list of rellocations -- you can specifiy what .exe to use on the command line as an optional 3rd parameter. But if the ASCII list of rellocation names contains strings it does not recognize (R_ARM_THM_CALL, say) , it will crap out with an "unknown rellocation type" error. (I just opened the BREWelf2mod.exe in my editor to see what R_ARM_XXX strings it contains -- that's how I know what relocs it supports -- assuming it does a strcmp() somewhere.)
So, my problem is, I can't find any incantation that generates a GNU ARM ELF file that only contains allocations BREWelf2mod recognizes. Even if I run an old (gnude) objdump against my new (sourcery) ELF exe to get old names for new relocs. Even if I just do ARM and not thumb code, I get R_ARM_CALL (unrecognized) and R_ARM_ABS32 (recognized) if I use the sourcery objdump, and R_ARM_RREL32 (unrecognized) R_ARM_ABS32 (recognized) if I use the gnude objdump (on the same 3.4.4 sourcery ARM ELF exe).
Since we can specify the objdump to execute, could we instead specify a wrapper executable, that could take the output from objdump and just convert it into whatever e2m expects?
wardw wrote:I can tell you that most of the space bloat in the MOD file is zeroes. For some reason, BREWelf2mod thinks it has to put the table of rellocation fixups WAY up high in the file.
So:
.text <---- 3MB+ of zeros --> relocation fixups | few more zeroes
Something about the 4.x scheme is confusing it about the section sizes -- I guess the size of the code in the .text section specifically. (BTW, this occurs even if I use the gnude ".xc" linker script. So at this point I don't think section layout is an issue, but...)
Could we just prune all the zeros padding? Would that also require modifying the relocation fixups, at least what stuff is addressing? Does the .mod contain a header that shows its filesize, and/or a hashvalue, to prevent tampering?

Quote:Could we just prune all the zeros padding? Would that also require modifying the relocation fixups, at least what stuff is addressing? Does the .mod contain a header that shows its filesize, and/or a hashvalue, to prevent tampering?
My guess is you could prune the zeroes. The fixup locations would still be correct. The startup code header would have to be stomped with the new offset of the relloc fixup table. I have not seen any filesize/hashvalue stuff (but that doesn't mean it is not there!).
Still, I would rather figure out how to make an ELF BREWelf2mod understands -- that is, find the root cause. Not ready to give up quite yet.
BTW, the other threads you mention on MOD size with gnu. First, my guess is, the code generation with the 4.x series is going to be better, second, GNU generated MODs have to carry around the relocation fixup table (in the current scheme) so they will have that overhead.
On the other hand, the GNU scheme lets you have un-inited globals, and tables of (function or other) pointers.
In short, I'm not aware of anyone seeing this specific problem before.

Quote:Could we just prune all the zeros padding? Would that also require modifying the relocation fixups, at least what stuff is addressing? Does the .mod contain a header that shows its filesize, and/or a hashvalue, to prevent tampering?
My guess is you could prune the zeroes. The fixup locations would still be correct. The startup code header would have to be stomped with the new offset of the relloc fixup table. I have not seen any filesize/hashvalue stuff (but that doesn't mean it is not there!).
Still, I would rather figure out how to make an ELF BREWelf2mod understands -- that is, find the root cause. Not ready to give up quite yet.
BTW, the other threads you mention on MOD size with gnu. First, my guess is, the code generation with the 4.x series is going to be better, second, GNU generated MODs have to carry around the relocation fixup table (in the current scheme) so they will have that overhead.
On the other hand, the GNU scheme lets you have un-inited globals, and tables of (function or other) pointers.
In short, I'm not aware of anyone seeing this specific problem before.

Quote:Since we can specify the objdump to execute, could we instead specify a wrapper executable, that could take the output from objdump and just convert it into whatever e2m expects?
Yes. Elsewhere I suggested using 'sed' or something like it. A shell program that exec()s objdump and converts its output might be easier to deal with in win32.
This works as long as it is only the names that have changed (and the fixup operation to be applied is the same). With the Sourcery toolchain -- that more closely tracks the EABI -- I'm not sure that was the case.
BREWelf2mod only seems to know how to do ((S+A)|T)-P and ((S+A)|T) operations. See "ELF for the ARM Architecture" ARM document GENC-003538v1.02 section 4.6 pp 21 on.

Quote:Since we can specify the objdump to execute, could we instead specify a wrapper executable, that could take the output from objdump and just convert it into whatever e2m expects?
Yes. Elsewhere I suggested using 'sed' or something like it. A shell program that exec()s objdump and converts its output might be easier to deal with in win32.
This works as long as it is only the names that have changed (and the fixup operation to be applied is the same). With the Sourcery toolchain -- that more closely tracks the EABI -- I'm not sure that was the case.
BREWelf2mod only seems to know how to do ((S+A)|T)-P and ((S+A)|T) operations. See "ELF for the ARM Architecture" ARM document GENC-003538v1.02 section 4.6 pp 21 on.

I just ran this command in Cygwin on the elf I created:
$ arm-elf-objdump.exe -r AirDate.elf | awk '{print $2}' | egrep "^R_" | sort | uniq -c
and I got this for output:
1193 R_ARM_ABS32
3710 R_ARM_PC24
3 R_ARM_PLT32
You mention R_ARM_ABS32 as a recognized relocation by e2m... what about the other two? Just wondering if they all are recognized by e2m, and therefore something else is wrong.

I just ran this command in Cygwin on the elf I created:
$ arm-elf-objdump.exe -r AirDate.elf | awk '{print $2}' | egrep "^R_" | sort | uniq -c
and I got this for output:
1193 R_ARM_ABS32
3710 R_ARM_PC24
3 R_ARM_PLT32
You mention R_ARM_ABS32 as a recognized relocation by e2m... what about the other two? Just wondering if they all are recognized by e2m, and therefore something else is wrong.

wardw wrote:Yes. Elsewhere I suggested using 'sed' or something like it. A shell program that exec()s objdump and converts its output might be easier to deal with in win32.
This works as long as it is only the names that have changed (and the fixup operation to be applied is the same). With the Sourcery toolchain -- that more closely tracks the EABI -- I'm not sure that was the case.
BREWelf2mod only seems to know how to do ((S+A)|T)-P and ((S+A)|T) operations. See "ELF for the ARM Architecture" ARM document GENC-003538v1.02 section 4.6 pp 21 on.
This only works if we know which relocations need remapping, and what they need remapping to. The rest is pretty easy to set up, but I'm not sure how we get that initial information. You're right when you say it would just be easiest to get an .elf format that e2m likes, but that may be hard to do.
What about reverting to the gcc version that e2m was created with? That might solve the problem, with the downside that we're using an older gcc. If an older gcc works, then maybe it's also possible to work out what changes are in the delta, and see if it's possible to recreate the switches required to output the right .elf format.

wardw wrote:Yes. Elsewhere I suggested using 'sed' or something like it. A shell program that exec()s objdump and converts its output might be easier to deal with in win32.
This works as long as it is only the names that have changed (and the fixup operation to be applied is the same). With the Sourcery toolchain -- that more closely tracks the EABI -- I'm not sure that was the case.
BREWelf2mod only seems to know how to do ((S+A)|T)-P and ((S+A)|T) operations. See "ELF for the ARM Architecture" ARM document GENC-003538v1.02 section 4.6 pp 21 on.
This only works if we know which relocations need remapping, and what they need remapping to. The rest is pretty easy to set up, but I'm not sure how we get that initial information. You're right when you say it would just be easiest to get an .elf format that e2m likes, but that may be hard to do.
What about reverting to the gcc version that e2m was created with? That might solve the problem, with the downside that we're using an older gcc. If an older gcc works, then maybe it's also possible to work out what changes are in the delta, and see if it's possible to recreate the switches required to output the right .elf format.

Quote:What about reverting to the gcc version that e2m was created with? That might solve the problem, with the downside that we're using an older gcc.
Using the gnude 3.3.1 toolchain certainly works. But, that is a 2003 compiler and the code is (probably) bigger and it couldn't compile my sources in thumb mode -- thumb seems broken, in fact.
So I want something modern I can go into production with.
But, I have a clue! The WinARM 4.1.0 compiler does not generate (empty) .data and .bss sections like gnude 3.3.1 does:
Test Program with GNUDE 3.3.1:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 008000 000788 00 AX 0 0 4
[ 2] .rel.text REL 00000000 008b3c 0001e8 08 10 1 4
[ 3] .rodata PROGBITS 00000788 008788 000050 01 AMS 0 0 4
[ 4] .data PROGBITS 000008d8 0088d8 000000 00 WA 0 0 1
[ 5] .sbss PROGBITS 000008d8 0088d8 000000 00 W 0 0 1
[ 6] .bss NOBITS 000008d8 0088d8 000000 00 WA 0 0 1
[ 7] .comment PROGBITS 00000000 0088d8 000036 00 0 0 1
[ 8] .stack PROGBITS 00080000 00890e 000000 00 W 0 0 1
[ 9] .shstrtab STRTAB 00000000 00890e 00004e 00 0 0 1
[10] .symtab SYMTAB 00000000 008d24 000270 10 11 23 4
[11] .strtab STRTAB 00000000 008f94 000172 00 0 0 1
Test program with WinARM 4.1.0:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 008000 000ba4 00 AX 0 0 4
[ 2] .rel.text REL 00000000 008dbc 000120 08 6 1 4
[ 3] .rodata PROGBITS 00000ba4 008ba4 000050 00 A 0 0 4
[ 4] .comment PROGBITS 00000000 008bf4 000051 00 0 0 1
[ 5] .shstrtab STRTAB 00000000 008c45 000036 00 0 0 1
[ 6] .symtab SYMTAB 00000000 008edc 0003b0 10 7 43 4
[ 7] .strtab STRTAB 00000000 00928c 000178 00 0 0 1
I know from running "strings" on BREWelf2mod it pays attention to .text, .rodata, .data and .debug. Since there is no (empty) .data section I think it can't find the end of the .text and goes nuts (and instead of a nice error just produces a huge file).
I'm going to try and do a custom linker script (I'm not an expert, but I've learned a lot the last few weeks!) I'm a little surprised because I used the gnude ld script with the winarm compile and it still came out this way, so I either made a pilot error or some default behavior of the linker has changed. Still, I hope it is "trickable" -- think it probably is.
Will advise...

Quote:What about reverting to the gcc version that e2m was created with? That might solve the problem, with the downside that we're using an older gcc.
Using the gnude 3.3.1 toolchain certainly works. But, that is a 2003 compiler and the code is (probably) bigger and it couldn't compile my sources in thumb mode -- thumb seems broken, in fact.
So I want something modern I can go into production with.
But, I have a clue! The WinARM 4.1.0 compiler does not generate (empty) .data and .bss sections like gnude 3.3.1 does:
Test Program with GNUDE 3.3.1:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 008000 000788 00 AX 0 0 4
[ 2] .rel.text REL 00000000 008b3c 0001e8 08 10 1 4
[ 3] .rodata PROGBITS 00000788 008788 000050 01 AMS 0 0 4
[ 4] .data PROGBITS 000008d8 0088d8 000000 00 WA 0 0 1
[ 5] .sbss PROGBITS 000008d8 0088d8 000000 00 W 0 0 1
[ 6] .bss NOBITS 000008d8 0088d8 000000 00 WA 0 0 1
[ 7] .comment PROGBITS 00000000 0088d8 000036 00 0 0 1
[ 8] .stack PROGBITS 00080000 00890e 000000 00 W 0 0 1
[ 9] .shstrtab STRTAB 00000000 00890e 00004e 00 0 0 1
[10] .symtab SYMTAB 00000000 008d24 000270 10 11 23 4
[11] .strtab STRTAB 00000000 008f94 000172 00 0 0 1
Test program with WinARM 4.1.0:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 008000 000ba4 00 AX 0 0 4
[ 2] .rel.text REL 00000000 008dbc 000120 08 6 1 4
[ 3] .rodata PROGBITS 00000ba4 008ba4 000050 00 A 0 0 4
[ 4] .comment PROGBITS 00000000 008bf4 000051 00 0 0 1
[ 5] .shstrtab STRTAB 00000000 008c45 000036 00 0 0 1
[ 6] .symtab SYMTAB 00000000 008edc 0003b0 10 7 43 4
[ 7] .strtab STRTAB 00000000 00928c 000178 00 0 0 1
I know from running "strings" on BREWelf2mod it pays attention to .text, .rodata, .data and .debug. Since there is no (empty) .data section I think it can't find the end of the .text and goes nuts (and instead of a nice error just produces a huge file).
I'm going to try and do a custom linker script (I'm not an expert, but I've learned a lot the last few weeks!) I'm a little surprised because I used the gnude ld script with the winarm compile and it still came out this way, so I either made a pilot error or some default behavior of the linker has changed. Still, I hope it is "trickable" -- think it probably is.
Will advise...

This only works if we know which relocations need remapping, and what they need remapping to.
R_ARM_THM_CALL needs to be changed to R_ARM_THM_PC22. ((S+A)|T)-P.
This is the common case and should make the winarm objdump work with 4.1.0 files. Now R_ARM_RREL32 from the sourcery chain is the one I don't know about. (But is only an issue if you use the sourcery chain.) It is not in the ARM docs. I seem to remember it had a real high type code, the ARM doc says that's "unallocated" ... so it is some strange domain or time specific artifact....

This only works if we know which relocations need remapping, and what they need remapping to.
R_ARM_THM_CALL needs to be changed to R_ARM_THM_PC22. ((S+A)|T)-P.
This is the common case and should make the winarm objdump work with 4.1.0 files. Now R_ARM_RREL32 from the sourcery chain is the one I don't know about. (But is only an issue if you use the sourcery chain.) It is not in the ARM docs. I seem to remember it had a real high type code, the ARM doc says that's "unallocated" ... so it is some strange domain or time specific artifact....

After I posted I looked at this size and noticed they were different. I grabbed the wrong file. Here is the correct comparison.
Test Program with WinARM:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 008000 000774 00 AX 0 0 4
[ 2] .rel.text REL 00000000 00898c 000120 08 6 1 4
[ 3] .rodata PROGBITS 00000774 008774 000050 01 AMS 0 0 4
[ 4] .comment PROGBITS 00000000 0087c4 000051 00 0 0 1
[ 5] .shstrtab STRTAB 00000000 008815 000036 00 0 0 1
[ 6] .symtab SYMTAB 00000000 008aac 0003a0 10 7 42 4
[ 7] .strtab STRTAB 00000000 008e4c 000178 00 0 0 1
Test Program with gnude:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 008000 000788 00 AX 0 0 4
[ 2] .rel.text REL 00000000 008b3c 0001e8 08 10 1 4
[ 3] .rodata PROGBITS 00000788 008788 000050 01 AMS 0 0 4
[ 4] .data PROGBITS 000008d8 0088d8 000000 00 WA 0 0 1
[ 5] .sbss PROGBITS 000008d8 0088d8 000000 00 W 0 0 1
[ 6] .bss NOBITS 000008d8 0088d8 000000 00 WA 0 0 1
[ 7] .comment PROGBITS 00000000 0088d8 000036 00 0 0 1
[ 8] .stack PROGBITS 00080000 00890e 000000 00 W 0 0 1
[ 9] .shstrtab STRTAB 00000000 00890e 00004e 00 0 0 1
[10] .symtab SYMTAB 00000000 008d24 000270 10 11 23 4
[11] .strtab STRTAB 00000000 008f94 000172 00 0 0 1

After I posted I looked at this size and noticed they were different. I grabbed the wrong file. Here is the correct comparison.
Test Program with WinARM:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 008000 000774 00 AX 0 0 4
[ 2] .rel.text REL 00000000 00898c 000120 08 6 1 4
[ 3] .rodata PROGBITS 00000774 008774 000050 01 AMS 0 0 4
[ 4] .comment PROGBITS 00000000 0087c4 000051 00 0 0 1
[ 5] .shstrtab STRTAB 00000000 008815 000036 00 0 0 1
[ 6] .symtab SYMTAB 00000000 008aac 0003a0 10 7 42 4
[ 7] .strtab STRTAB 00000000 008e4c 000178 00 0 0 1
Test Program with gnude:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 008000 000788 00 AX 0 0 4
[ 2] .rel.text REL 00000000 008b3c 0001e8 08 10 1 4
[ 3] .rodata PROGBITS 00000788 008788 000050 01 AMS 0 0 4
[ 4] .data PROGBITS 000008d8 0088d8 000000 00 WA 0 0 1
[ 5] .sbss PROGBITS 000008d8 0088d8 000000 00 W 0 0 1
[ 6] .bss NOBITS 000008d8 0088d8 000000 00 WA 0 0 1
[ 7] .comment PROGBITS 00000000 0088d8 000036 00 0 0 1
[ 8] .stack PROGBITS 00080000 00890e 000000 00 W 0 0 1
[ 9] .shstrtab STRTAB 00000000 00890e 00004e 00 0 0 1
[10] .symtab SYMTAB 00000000 008d24 000270 10 11 23 4
[11] .strtab STRTAB 00000000 008f94 000172 00 0 0 1