From "LCC-Win32 Technical Reference", page 112, by Jacob Navia.

The standard sections that lcclnk understands and uses are the following:

.text: The code of the program. These are sequences of bytes that the processor
       you are using "understands" This bytes are interpreted by the processor as
       a series of instructions, executed, etc. All the executable and all computer
       processing comes down to this: a series of numbers that the processor executes
       in an absolutely stupid way.

.data Here come the initialized data items, i.e. data that is know to the program at
      program start.

.bss: Non initialized data. This is just RAM space reserved for future use by the
      program at the program start. This name "non-initialized" data is a misnomer
      since this RAM will be cleared to zero by the program loader.

.idata: The imports table. This is a table constructed by the different "import libraries"
        and several sections in the startup code, that tells the program loader which dll
        to search and which functions in that dll to link at load time.

.edata: The exports table. In the case of a dll, this tells the program loader, which
        functions this dll exports.

.rdata. Several small information pieces about the executable, like the position of
        the Coff debug header, and other trivia. Not really necessary, and I am
        thinking that in a future version of the linker I could well just ignore it.

.reloc: Relocation information telling the program loader which sections to fix if
        the program can’t be loaded at its default load address, the Image base value
        we discussed above.

.rsrc: Resources of the application.

.reloc: Relocation information for the program loader. This is used only in Dlls.

.debug: Debugging information. The program loader at startup does not load this section.