Description
An assembler source file is allowed to contain multiple AREAs, however, if it is assembled with debug enabled (-g) and the image loaded into a debugger, the debuggers are then not able to display the corresponding source (debug) information. Note that the object code is built correctly - it is only the debug information that is corrupted.

Solution
Consider the following example:

        AREA    Area1, CODE, READONLY  ; first AREA in source
        ENTRY
 ;...
        BL label 

        AREA    Area2, CODE, READONLY  ; second AREA in source
label
 ;...
        END 

The solution is to separate these two AREAs and to place each one into a separate source files.

If your original reason for declaring the two AREAs in the single source was to try to place them contiguously in the memory map, then be aware that this may not happen anyway, because armlink uses specific placement rules to order AREAs in the map (see SDT 2.50 Reference Guide, section 6.9, Area placement and sorting rules).

If this is what is being attempted, then this can be achieved by placing the AREAs into two separate source files (and hence two different objects, for example area1.o and area2.o), and use scatterloading. The scatterfile might look like:

ROM 0x100000 0x100000
{
    ROM_1 0x100000
    {
        area1.o (Area1, +FIRST) ; First AREA in Execution Region
        area2.o (Area2)         ; Immediately following as only
    }                           ; two AREAs in Execution Region
    ROM_2 +0                    ; Immediately following (+0)
    {
        * (+RO)                 ; All other RO AREAs
    }
    RAM 0x200000
    {
        * (+RW, +ZI)            ; ALL RW and ZI AREAs
    }
} 

In the above example, we have only placed two AREAs in ROM_1 Execution region, and so by forcing area1.o to be placed first (by use of +FIRST), area2.o shall automatically be placed at the next word aligned address. Any other AREAs can be placed in another execution region (e.g. ROM_2 above), and by using the +0 directive, shall be placed at next (word aligned) address in the memory map.

For more information on Scatterloading:

• SDT 2.50/2.51 users should refer to SDT 2.50 Reference Guide, Chapter 6, 'Linker' and SDT 2.50 User Guide, Chapter 10, 'Writing Code for ROM'.
• SDT 2.11/2.11a users should refer to the SDT 2.11 User Guide, section 14, 'Placing Code and Data in Memory' and Application Note 48, Scatter Loading, in the ARM Application Notes.