Relocatable Linker Version 4.9.6 generates wrong MAP file information

Typically when creating a relocatable module the linker is concerned with creating the output sections but not actually allocating them. I'm not clear where the RAM memory configuration starting at 0x20 is coming from in the map file. If I try to relink the BSW_boot.lno to create an executable with a linker command file that specifies a different memory origin, then the .text gets allocated correctly to it and the symbol Write_32_bit_To_CRC_Low_Register gets the correct address at an offset of 0x11 from the start of .text.

However, I'm not sure why it is setting the RAM origin to 0x20 and placing the .text there. I will try to get some other experts to take a look and comment.

I doubt that the linker is broken.  It appears that you have somehow defined the linker symbol START_OF_READ_FLASH_ROUTINE as 32 (aka 0x20).

Hello Aarti,

I am attaching a new ZIP file.

Please unzip to a FOLDER.

Run Linker_Bug.bat file assuming Linker 4.9.6 path is correct as mentioned in the BAT file. Else change accordingly.

You will see dbcBootCAN.map file is being created.

The error I am talking about is as below:

START_OF_READ_FLASH_ROUTINE symbol address is 0x80

Write_32_Bit_To_CRC_Low_Register symbol address is 0x71

That should not be the case because linkeri_boot_lno_ti.cmd contains

    .text :
                     {
              .\read_flash_area.obj   (.text)  {START(START_OF_READ_FLASH_ROUTINE) END(END_OF_READ_FLASH_ROUTINE)}                  
              *   (.text)
                     }          

Write_32_Bit_To_CRC_Low_Register symbol is afunction within read_flash_area.obj.

This is the BUG I am talking about.

In my previous mail, I provided you the root cause.

In this mail, I am showing you the end result of the error.

Please help soon.

Thank you.

Regards

Pashan

When I run Linker_Bug.bat I don't see anywhere actually using linkeri_boot_lno_ti.cmd. As such, I see START_OF_READ_FLASH_ROUTINE=0x80 as you say.

If I add linkeri_boot_lno_ti.cmd to the last link command in Linker_Bug.bat before the other .cmd files, then the value becomes START_OF_READ_FLASH_ROUTINE=0xf970.  I have no idea if that is the value you expect because I don't know where in the .cmd file order it belongs, but since I don't see the .cmd file being used in the steps you sent I want to clarify where linkeri_boot_lno_ti.cmd is supposed to being used.

EDIT:

I found the command in relocate_link_bug.bat which uses linkeri_boot_lno_ti.cmd and links read_flash_area.obj

In that relocatable link step that uses linkeri_boot_lno_ti.cmd and links in read_flash_area.obj, the linker command file says to create symbol START_OF_READ_FLASH_ROUTINE and set it equal to the beginning of the .text section from the read_flash_area.obj file.  But because this is a relocatable link, the .text section from read_flash_area.obj will be allocated at least one more time in a later link, and so the address of Write_32_Bit_To_CRC_Low_Register (which is 11 bytes into the .text section from what I can see) will change, and will virtually start at zero until the absolute link, but START_OF_READ_FLASH_ROUTINE will continue to point to where the .text section from read_flash_area.obj is allocated.

I'm not sure how the interaction between the symbol at the beginning of the .text section from a file, and the relocation address of a function within that section is intended to be maintained during multiple partial links, and will need to ask a few other developers who are out this week.

Hello Support,

I am attaching the file.

Please unzip to a sub-folder.

From the previous post, I just modified relocate_linker_bug.bat file to use 4.6.4 Linker.

If you run the same steps as before you will see that within dbcBootCAN.MAP file

START_OF_READ_FLASH_ROUTINE is at 0x60

Write_32_Bit_To_CRC_Low_Register is at 0x73

This is correct behaviour as expected.

Hence, I think 4.9.6 Linker is having some BUG.

Please help me decipher this discrepancy. Let me know if you need any more information to understand this BUG.

Thank you.

Regards

Pashan

Please note that I am still looking at this on and off and talking to others.  The test case is complex, and it is not clear how the various features are intended (from the point of view of the compiler tools) to interact thru so many and different relocatable links.

I've noted that the allocation of the two symbols varies greatly between the two versions and am trying to understand the differences to find where an error might have occurred.

Hello Wolf/Aarti,

Any news about this probelm described in this mail chanin?

Thank you.

Regards

Pashan

Hello Worl/Aarti,

Can you please help me with this BUG I am talking about?

I am eagerly waiting to hear from you regarding the status of this BUG.

Any help is appreciated.

Or, at least tell me the BUG Report Number within ClearQuest.

Thank you.

Regards

Pashan