Allow section address to be set from address map using name of section

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a custom section (.custom) which has same permissions as .data section
2. Link with option --start-section to set distinct addresses to both .data and 
.custom
3.

This creates a executable with the above mentiones sections having same address 
(value depending on who comes out of address map first). Here is an observation 
made in hexagon executable (note the addresses marked with nesting of three *): 
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .init             PROGBITS        00000100 000100 000054 00  AX  0   0 32
  [ 2] .start            PROGBITS        ***1f000000*** 001000 003dc0 00 WAX  0   0 64
  [ 3] .text             PROGBITS        1f005000 005000 001e6c 00  AX  0   0 4096
  [ 4] .fini             PROGBITS        1f006e80 006e80 000030 00  AX  0   0 32
  [ 5] .rodata           PROGBITS        1f006eb0 006eb0 0000e1 00   A  0   0  4
  [ 6] .eh_frame         PROGBITS        1f006fa0 006fa0 000004 00   A  0   0 32
  [ 7] .data             PROGBITS        ***1f000000*** 007000 0005c3 00  WA  0   0  8

To solve this, we must not set the section address merely noting its 
permissions using isData / isBSS etc but to actually see the name. This logic 
seems appropriate because we use the name of section to set address so we must 
always use the name when we are trying to fix its address in the output 
section. Attached is the file to fix this problem. 

Original issue reported on code.google.com by khem...@codeaurora.org on 23 Apr 2013 at 9:35

Attachments:

• 0001-Allow-section-start-to-be-determined-by-the-name-of-.patch

[GoogleCodeExporter]

Corrections abt last Para:
This logic seems appropriate because we use the name of section to set address 
on command line options so we must always use the name when we are trying to 
fix its address in the output section. Attached is the file to fix this problem

Original comment by khem...@codeaurora.org on 23 Apr 2013 at 9:37

[GoogleCodeExporter]

Dear Peter,

Please review this patch.

Original comment by LubaTang on 26 Apr 2013 at 9:39

[GoogleCodeExporter]

Any update on this one?

Thanks,
Hemant

Original comment by khem...@codeaurora.org on 14 May 2013 at 7:23