1

I am getting the following error messages, and I checked the file but can not figure out why or how to address the errors. Please help. 

arch/arm/mach-msm/jtag-mm.o: In function `dbg_init_arch_data':
/home/sansari/WORKING_DIRECTORY/arch/arm/mach-msm/jtag-mm.c:279: multiple definition of `msm_jtag_save_cntr'
arch/arm/mach-msm/jtag.o:/home/sansari/WORKING_DIRECTORY/arch/arm/mach-msm/jtag.c:1085: first defined here
arch/arm/mach-msm/jtag-mm.o: In function `etm_init_arch_data':
/home/sansari/WORKING_DIRECTORY/arch/arm/mach-msm/jtag-mm.c:568: multiple definition of `msm_jtag_save_state'
arch/arm/mach-msm/jtag.o:/home/sansari/WORKING_DIRECTORY/arch/arm/mach-msm/jtag.c:1038: first defined here
arch/arm/mach-msm/jtag-mm.o: In function `msm_jtag_restore_state':
/home/sansari/WORKING_DIRECTORY/arch/arm/mach-msm/jtag-mm.c:585: multiple definition of `msm_jtag_restore_state'
arch/arm/mach-msm/jtag.o:/home/sansari/WORKING_DIRECTORY/arch/arm/mach-msm/jtag.c:1073: first defined here
arch/arm/mach-msm/jtag-mm.o: In function `dbg_init_arch_data':
/home/sansari/WORKING_DIRECTORY/arch/arm/mach-msm/jtag-mm.c:279: multiple definition of `msm_jtag_restore_cntr'
arch/arm/mach-msm/jtag.o:/home/sansari/WORKING_DIRECTORY/arch/arm/mach-msm/jtag.c:1085: first defined here
make[1]: *** [arch/arm/mach-msm/built-in.o] Error 1

I put a copy of jtag-mm.c at this link

Thanks. Here is jtag.c

After commenting out the jtag.h, and recompiling I get the following error message: 

arch/arm/mach-msm/jtag-mm.c:790:2: error: implicit declaration of function 'msm_jtag_fuse_apps_access_disabled' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-msm/jtag-mm.o] Error 1
make: *** [arch/arm/mach-msm] Error 2

@Peter - Thanks. I get what you are saying. Ok. let me try it. Never mind about the grep comment:-) I see it is not possible.

Update: Thanks. I can see what the issue is now. Now that I have posted the jtag.h, and jtag-mm.c, and jtag.c, you can perhaps validate what I think is the issue. As Peter mentioned, the variables are declared twice. Once by jtag.c and again by jtag-mm.c. For instance, I see the lines: 

uint32_t msm_jtag_save_cntr[NR_CPUS];
uint32_t msm_jtag_restore_cntr[NR_CPUS];

in both files. But I tried to comment them out in one file, and I get an error since the variable is used in the same file in a function. What is the right way of handling this then? Can I declare it in the header file once, and just remove it from both source files? Or should I leave the deceleration in one source file, and include it in the other?

Here is a copy of jtag.h Thanks

user3326293
  • 817
  • 1
  • 14
  • 37
  • we also need to see the contents of jtag.c. However, it seems that both the .c files contain 4 functions that have the same name in both files. – user3629249 Jun 08 '15 at 00:38
  • 1) most/all of the functions are declared 'static' then some of the function names are being exported using the 'EXPORT_SYMBOL' . In general, not a good idea to make 'static' functions globally visible. 2) many of the functions have the 'inline' modifier, however, the functions are very large. Therefore, the compiler will not 'inline' them. and the trivial savings from the removal of the call/return sequences would be swamped if those functions are being invoked from more that one location. 3) inline functions should be in header files, so multiple source can inline them – user3629249 Jun 08 '15 at 00:48
  • within the file, the 'inline'd functions are (I did not check them all) only invoked once and the functions are large. so: 1) the functions will not be 'inline'd 2) inline is only practical for VERY short functions that are called multiple times – user3629249 Jun 08 '15 at 00:53
  • 2 of the 4 functions with the duplicate definitions are in the jtag-mm.c file. It seems all 4 of the duplicate functions are defined/exported in the jtag.c file. Strongly suggest using unique names for functions, perhaps removing the '#include ' line from the jtag_mm.c file would help. – user3629249 Jun 08 '15 at 00:58

1 Answers1

0

You haven't shown the jtag.h file, so it is only possible to speculate on what it is doing.

Since most of the errors disappear on "commenting out the jtag.h", the most likely explanation is that the header file has definitions, and one of the source files is #includeing that header file more than once (directly or - more likely - indirectly, due to other header files #includeing it). A common solution to that is to add include guards to the header file of the form

 #ifndef SOME_MACRO_CHOSEN_TO_BE_UNIQUE_TO_THE_HEADER
 #define SOME_MACRO_CHOSEN_TO_BE_UNIQUE_TO_THE_HEADER

   /*  the content of the header file

 #endif

You may also (after fixing the above, so the compiler stops choking on your code) get linker errors. That will result from multiple source files #includeing your header - hence the linker seeing symbols defined in multiple object files. The solution to that one will be to move the offending definitions (typically of either functions or static variables) from the header file to ONE (and only ONE) of the source files in your project.

Peter
  • 35,646
  • 4
  • 32
  • 74
  • I tried removing the offending declaration from one of the source files. But I get error: 'msm_jtag_save_cntr' undeclared. How do I address that? Can I put the declaration in the header file? – user3326293 Jun 09 '15 at 11:06
  • If you're happy for the variable to be shared between the source file, then declare it `extern` in the header (i.e. `extern uint32_t msm_jtag_save_cntr[NR_CPUS];`), then define it in ONE and only ONE of the source files (i.e. `uint32_t msm_jtag_save_cntr[NR_CPUS];`). Bear in mind that changes made to that variable/array in any source file will be visible to code in the other source file. That's only a stop-gap though - your real problem is duplicating code between source files without understanding the implications (several ways to get in trouble doing that). – Peter Jun 09 '15 at 12:43
  • Thanks. I am just after functionality for now. I believe the issue of duplicating code among source files has security implications? I am not concerned with that right now, as this would be a prototype image. – user3326293 Jun 09 '15 at 12:53
  • I'm not referring to security implications. I'm referring to basic problems that come by having code in one source file doing unexpected things to a variable that is used in another source file. Duplicating code between source files certainly introduces maintenance problems though- as you are demonstrating. – Peter Jun 09 '15 at 13:27
  • You don't know how much I appreciate this. Not only I addressed my problem, I learned about the implications of changing the config. Thank you so much. – user3326293 Jun 09 '15 at 14:18