behavior of string literal in rodata section of shared object

Question

#include <stdio.h>
#include <string.h>

#define CONFDIR "/opt/hp9300/pov64_IworkspaceIdocpv989Ieightonews-r7.6-dev_tests-000001"
#define NEW_CONFDIR "/etc" CONFDIR
// test.c
int foo() {
  char confdir[127+1]; // plz ignore the buffer checks
  strcpy(confdir, NEW_CONFDIR);
  // strncpy(confdir, NEW_CONFDIR, sizeof(confdir));
  return 0;
}

// output when strcpy
// objdump -s test.so
// no .rodata section, only .text

Contents of section .text:
 1040 488d3dc1 2f000048 8d05ba2f 00004839  H.=./..H.../..H9
 1050 f8741548 8b056e2f 00004885 c07409ff  .t.H..n/..H..t..
 1060 e00f1f80 00000000 c30f1f80 00000000  ................
 1070 488d3d91 2f000048 8d358a2f 00004829  H.=./..H.5./..H)
 1080 fe4889f0 48c1ee3f 48c1f803 4801c648  .H..H..?H...H..H
 1090 d1fe7414 488b053d 2f000048 85c07408  ..t.H..=/..H..t.
 10a0 ffe0660f 1f440000 c30f1f80 00000000  ..f..D..........
 10b0 f30f1efa 803d4d2f 00000075 2b554883  .....=M/...u+UH.
 10c0 3d1a2f00 00004889 e5740c48 8d3d2e2d  =./...H..t.H.=.-
 10d0 0000e859 ffffffe8 64ffffff c605252f  ...Y....d.....%/
 10e0 0000015d c30f1f00 c30f1f80 00000000  ...]............
 10f0 f30f1efa e977ffff ff554889 e54883ec  .....w...UH..H..
 1100 08488d45 8048ba2f 6574632f 6f707448  .H.E.H./etc/optH
 1110 b92f6870 39333030 2f488910 48894808  ./hp9300/H..H.H.
 1120 48be706f 7636345f 497748bf 6f726b73  H.pov64_IwH.orks
 1130 70616365 48897010 48897818 48ba4964  paceH.p.H.x.H.Id
 1140 6f637076 393848b9 39496569 6768746f  ocpv98H.9Ieighto
 1150 48895020 48894828 48be6e65 77732d72  H.P H.H(H.news-r
 1160 372e48bf 362d6465 765f7465 48897030  7.H.6-dev_teH.p0
 1170 48897838 48ba6576 5f746573 747348b9  H.x8H.ev_testsH.
 1180 2d303030 30303100 4889503b 48894843  -000001.H.P;H.HC
 1190 b8000000 00c9c3                      .......         


// output when strncpy
// objdump -s test.so
// readelf -p ".rodata" test.so
Contents of section .rodata:
 2000 2f657463 2f6f7074 2f687039 3330302f  /etc/opt/hp9300/
 2010 706f7636 345f4977 6f726b73 70616365  pov64_Iworkspace
 2020 49646f63 70763938 39496569 6768746f  Idocpv989Ieighto
 2030 6e657773 2d72372e 362d6465 765f7465  news-r7.6-dev_te
 2040 7374732d 30303030 303100             sts-000001.     

// output when strncpy
// readelf -p ".rodata" test.so
String dump of section '.rodata':
  [     0]  /etc/opt/hp9300/pov64_IworkspaceIdocpv989Ieightonews-r7.6-dev_tests-000001

when I compile it on Linux using gcc -o test.so -fPIC -shared -g and inspect the string constants of shared lib test.so using objdump or strings, I see a sub-string of NEW_CONFDIR, truncated to multiple of 16 bytes.

But, if I change the code to use strncpy (as shown in the code above) and compile again with the same set of flags, it shows full string with no truncation.

Is this expected, does compiler do any optimization with string constants ? Or there is an issues with using strcpy and strncpy in this case and their effect on rodata of shared object files ?

I am only concerned about the compilation phase and generation of shared objects not actual execution of code. The tool searches rodata of shared libs for NEW_CONFDIR.

Answer 1

I reproduced this behavior: take the OP's source, compile with gcc -o test.so -fPIC -shared -g, run strings test.so:

_ITM_deregisterTMCloneTable
_ITM_registerTMCloneTable
__cxa_finalize
u+UH
/etc/optH
/hp9300/H
pov64_IwH
orkspaceH
Idocpv98H
9IeightoH
news-r7.H
6-dev_teH
ev_testsH
-000001
;*3$"
GCC: (Debian 13.2.0-5) 13.2.0
...

So let's figure out what's going on. objdump -d test.so shows:

00000000000010f9 <foo>:
    10f9:       55                      push   %rbp
    10fa:       48 89 e5                mov    %rsp,%rbp
    10fd:       48 83 ec 08             sub    $0x8,%rsp

; RAX = &configdir[0]
    1101:       48 8d 45 80             lea    -0x80(%rbp),%rax 
    1105:       48 ba 2f 65 74 63 2f    movabs $0x74706f2f6374652f,%rdx
    110c:       6f 70 74
    110f:       48 b9 2f 68 70 39 33    movabs $0x2f3030333970682f,%rcx
    1116:       30 30 2f

; copy 8 bytes "/etc/opt" to &confdir[0]
    1119:       48 89 10                mov    %rdx,(%rax)

; copy "/hp9300/" to &confdir[8]
    111c:       48 89 48 08             mov    %rcx,0x8(%rax)

; ... etc.
    1120:       48 be 70 6f 76 36 34    movabs $0x77495f3436766f70,%rsi
    1127:       5f 49 77
    112a:       48 bf 6f 72 6b 73 70    movabs $0x65636170736b726f,%rdi
    1131:       61 63 65
    1134:       48 89 70 10             mov    %rsi,0x10(%rax)
    1138:       48 89 78 18             mov    %rdi,0x18(%rax)
    113c:       48 ba 49 64 6f 63 70    movabs $0x38397670636f6449,%rdx
    1143:       76 39 38
    1146:       48 b9 39 49 65 69 67    movabs $0x6f74686769654939,%rcx
    114d:       68 74 6f
    1150:       48 89 50 20             mov    %rdx,0x20(%rax)
    1154:       48 89 48 28             mov    %rcx,0x28(%rax)
    1158:       48 be 6e 65 77 73 2d    movabs $0x2e37722d7377656e,%rsi
    115f:       72 37 2e
    1162:       48 bf 36 2d 64 65 76    movabs $0x65745f7665642d36,%rdi
    1169:       5f 74 65
    116c:       48 89 70 30             mov    %rsi,0x30(%rax)
    1170:       48 89 78 38             mov    %rdi,0x38(%rax)
    1174:       48 ba 65 76 5f 74 65    movabs $0x73747365745f7665,%rdx
    117b:       73 74 73
    117e:       48 b9 2d 30 30 30 30    movabs $0x3130303030302d,%rcx
    1185:       30 31 00
    1188:       48 89 50 3b             mov    %rdx,0x3b(%rax)
    118c:       48 89 48 43             mov    %rcx,0x43(%rax)
    1190:       b8 00 00 00 00          mov    $0x0,%eax
    1195:       c9                      leave
    1196:       c3                      ret

This explains why the string is broken up into 8-byte chunks, but where does the (9-th) H come from?

Look at the byte following the "string" constant starting at 0x1122. The MOVABS ..., %rcx instruction code is 0x48 0xbf, and 0x48 just happens to "spell" H, and that's why there is an H there.

Also, 0xbf just happens to not be ASCII, thus breaking the string.

If the opcode for MOVABS ..., %rcx was 0x48 0x5f instead, your "string" would look like /etc/optH_/hp9300/....

Related answer about AWAVAUATUSH and similar strings.

---

So what happens when you use strncpy ?

The compiler decides to call external version instead of inlining the strncpy:

objdump -d test.so
...
0000000000001109 <foo>:
    1109:       55                      push   %rbp
    110a:       48 89 e5                mov    %rsp,%rbp
    110d:       48 83 c4 80             add    $0xffffffffffffff80,%rsp
    1111:       48 8d 45 80             lea    -0x80(%rbp),%rax
    1115:       ba 80 00 00 00          mov    $0x80,%edx
    111a:       48 8d 0d df 0e 00 00    lea    0xedf(%rip),%rcx        # 2000 <_fini+0xecc>
    1121:       48 89 ce                mov    %rcx,%rsi
    1124:       48 89 c7                mov    %rax,%rdi
    1127:       e8 04 ff ff ff          call   1030 <strncpy@plt>
    112c:       b8 00 00 00 00          mov    $0x0,%eax
    1131:       c9                      leave
    1132:       c3                      ret

P.S. You can ask GCC to not inline strcpy with -fno-builtin-strcpy, and that will "restore" the full string (because GCC will call external strcpy from libc with that flag).