TMS320F28386S: Extraneous Data in Linker Output

Hi, 

Do you know section names that you are seeing but don't expect to see? 

What are the compiler options and the compiler version that you are using?

Will forward this query to the compiler team to assist you better.

Best Regards

Siddharth

Hi Siddarth,

                The code has no sections which would result in that data.  So I don’t know what it could be.  We are using compiler version TI v20.2.5.LTS.  The compiler flags are as follows:

-v28 -ml -mt --cla_support=cla2 --float_support=fpu64 --idiv_support=idiv0 --tmu_support=tmu0 --vcu_support=vcrc --include_path=<include path 0> --include_path=<include path 1> <more include paths> -g --diag_warning=225 --diag_wrap=off --display_error_number --gen_func_subsections=on --abi=eabi --asm_listing

Thank you,

Ed

Hello Ed,

While running the device in a debug session were you able to view this memory in the Memory Browser window? Can you view the address where this occurs?

Ed Sanders said:

It also contains a class name which is part of the source code, but should not be in the output of the build process.

Can you clarify this? I'm not sure what you mean by it should not be in the output of the build process.

Hi Omer,

I discovered the issue because I set up the linker to produce a TI-TXT output.  In that file, I am seeing the class name, along with other things.  The snippet I provided in the first post contains one of the other things.  I didn’t include enough to expose the class name (type).  But the part which I included, translates into the ASCII as below:

N.1.0._._.c.x.x.a.b.i.v.1.2.3._._.f.u.n.d.a.m.e.n.t.a.l._.t.y.p.

Our code does not use any class names or any of the other things in the run-time result, and as such, they should not appear in the final image which is loaded into flash.

Does this help?

Thank you,

Ed

Hello Ed,

So from my understanding, the code build but for some reason there is an extra section where the values you cited above are appearing. This data appears at "@<my address>" (I would like to know what address this is, rather than just a name) and contains a class name which does not exist (which I don't believe I know the name of, so I'll have to trust that this is some code that you have verified is not in driverlib or anywhere in C2000Ware). This is not affecting the functionality of your code, but you're trying to find out why this section is created and if there's a way to remove it, correct?

Unfortunately the problem on my side is that I don't know where this memory is being inserted for you, or whether or not the class actually exists since I don't have the name to look for in C2000Ware (in case it's something that's pulled in from there). It would also help if you could provide both TI_TXT outputs so I can compare them wholly, although I understand if you have confidential code/data in there (in which case you can try to re-create this on a smaller scale project).

Hi Omer,

I can give you some more info as a private message.  But I'm not seeing a way to do it.  I tried hovering over your picture, but a private message is not one of the options.  Is there another way to do it?

Thank you,

Ed

I think you have to create a friend request first.

OK.  I have done that.

Ed

Okay, we'll handle this offline and I will reply to this post once we have something that can be publicly posted (for future customers' reference).

From the offline conversation, I have determined that the textual information is in the .const section.  The construction of our class is such that it inherits from a base class which has pure virtual methods in it.  When I comment out those, the issue goes away.  I checked the equivalent section in the 379D project, which uses the same class with no modifications, and I don’t see any of the textual information in it.  I do see the class V table entries which is expected.

Thank you,

Ed

Hello Ed,

I discovered the issue because I set up the linker to produce a TI-TXT output.

Strictly speaking, the linker does not produce TI-TXT. It produces a linked executable that is then given to another tool to convert it to TI-TXT output.  When the link completes, there are files produced, including a MAP file, that show the origin input section that comprise each output section.  However, it sounds like you have tracked this information to vtable artifacts, including strings for function name information.  So the question remains why are these strings being included since they take up memory if they're part of .const

Would it be possible to post a cut-down test case that show this so that we can compile and reproduce this?  I'm interested in the generated object code / executable and not the TI-TXT formatted data.  Please follow the directions in the article How to Submit a Compiler Test Case

Hi Alan,

                I have attached the pp file, and the compiler options, which show the compiler version, are pasted below.  If that doesn’t help, I have boiled the whole thing down to a very simple project which I could submit.

class PARENT_CLASS
   {
   public:
      PARENT_CLASS() {};
      ~PARENT_CLASS() {}

      virtual void   Do_PureVirtualMethod(void) = 0;
  };

class CHILD_CLASS : public PARENT_CLASS
{
public:
   CHILD_CLASS() {}

   void  Do_PureVirtualMethod(void);
};

void  CHILD_CLASS::Do_PureVirtualMethod(void)
   {
   }

"C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/bin/cl2000" -v28 -ml -mt --cla_support=cla2 --float_support=fpu64 --idiv_support=idiv0 --tmu_support=tmu0 --vcu_support=vcrc --include_path="C:/ClassNameInTiTxt" --include_path="C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/include" -g --preproc_with_comment --preproc_with_compile --diag_warning=225 --diag_wrap=off --display_error_number --gen_func_subsections=on --abi=eabi --asm_listing  "../ChildClass.cpp"

Finished building: "../ChildClass.cpp"

Thank you,

Ed

Thank you for the test case.  I build it the same way, except I add the option --src_interlist.  This option causes the generated assembly file to be kept.  It has the same name as the source file, with the extension changed to .asm.  This file contains these lines ...

	.global	||_ZTS11CHILD_CLASS||
	.sect	".const:.typeinfo:_ZTS11CHILD_CLASS"
	.align	1
	.elfsym	||_ZTS11CHILD_CLASS||,SYM_SIZE(14)
||_ZTS11CHILD_CLASS||:
	.bits		0x31,16
			; _ZTS11CHILD_CLASS[0] @ 0
	.bits		0x31,16
			; _ZTS11CHILD_CLASS[1] @ 16
	.bits		0x43,16
			; _ZTS11CHILD_CLASS[2] @ 32
	.bits		0x48,16
			; _ZTS11CHILD_CLASS[3] @ 48
	.bits		0x49,16
			; _ZTS11CHILD_CLASS[4] @ 64
	.bits		0x4c,16
			; _ZTS11CHILD_CLASS[5] @ 80
	.bits		0x44,16
			; _ZTS11CHILD_CLASS[6] @ 96
	.bits		0x5f,16
			; _ZTS11CHILD_CLASS[7] @ 112
	.bits		0x43,16
			; _ZTS11CHILD_CLASS[8] @ 128
	.bits		0x4c,16
			; _ZTS11CHILD_CLASS[9] @ 144
	.bits		0x41,16
			; _ZTS11CHILD_CLASS[10] @ 160
	.bits		0x53,16
			; _ZTS11CHILD_CLASS[11] @ 176
	.bits		0x53,16
			; _ZTS11CHILD_CLASS[12] @ 192
	.bits		0,16
			; _ZTS11CHILD_CLASS[13] @ 208

Among other things, the .bits directives form the string 11CHILD_CLASS.  This is part of the type information for the class.  

According to this from the first post ...

Ed Sanders said:

I am porting code from a 379D project to the 386S, and have told the linker to produce a TI-TXT output file.  When I examine that file, I see the sections I expect to see.  But I also see another section I cannot explain.  It contains text (maybe Unicode?) which is not part of the code.  It also contains a class name which is part of the source code

... the previous build must not have this type information.  I cannot explain this difference.  I expect both builds would have the type information.

Please provide a test case based on the 379D project, similar to the last test case you provided.  I presume that when I build it, I will not see the type information.  I would like to explain why that happens.

Thanks and regards,

-George

Hi George,

Sorry for the tardy response.  Our email server was rejecting inbound emails.  So I polled, and found your response.

I changed the processor to the 379D, and rebuilt with the same result.  The class name is in the TI-TXT file.  Could it be an issue, not with the linker, but with the tool which creates the TI-TXT file?

I have boiled this down to two project, one for the 388D and one for the 379d.  Neither should have any of our IP in them.  If it would help, I could zip them up and PM them to you.

Thank you,

Ed

Ed Sanders said:

I have boiled this down to two project, one for the 388D and one for the 379d

Please compare the compile (not link) options.  Does one use --abi=eabi, and the other does not?

Thanks and regards,

-George

Hi George,

They both use --abi=eabi.  That is probably to be expected because when I made the second project for the 379D, I copied the 388D project and only changed the DSP.  So I changed the settings to COFF, and now I no longer see the class name in the TI-TXT output in the 379D project.

Ed 

Going back to the first post ...

Ed Sanders said:

I am porting code from a 379D project to the 386S

I presume the older project builds with the older COFF ABI, and the newer project builds with the newer EABI.  Each ABI handles C++ type information differently.  Is all of that correct?  Can this thread be closed?

Thanks and regards,

-George

Hi George,

Both projects build.  But in the projects which use EABI, the TI-TXT file contains a lot of textual information, such as the class name, which is not part of the executable.  And the address for that information is in the flash space.  So the top level problem is that the extraneous information is consuming valuable space in the flash.

To continue the investigation, as another experiment, I tried changing the 388D project to use COFF, and needed to change fpu and div settings too.  But that also succeeded in removing the textual information from the TI-TXT file.  So it seems that the EABI is adding additional things to the flash, or the tool which converts it to the TI-TXT format is adding it.

Does this help?

Thank you,

Ed