8000 Dynamic string table is difficult to use because string offsets cannot be computed before layout · Issue #94 · qualcomm/eld · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Dynamic string table is difficult to use because string offsets cannot be computed before layout #94

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
partaror opened this issue May 16, 2025 · 0 comments · May be fixed by #95
Open

Dynamic string table is difficult to use because string offsets cannot be computed before layout #94

partaror opened this issue May 16, 2025 · 0 comments · May be fixed by #95
Assignees
@partaror
Labels
refactor

Comments

@partaror
Copy link
partaror commented May 16, 2025 •
edited
Loading

Dynamic string table (ELFFileFormat::f_pDynStrTab) is difficult to use because the string offsets of the strings in the dynamic string table cannot be computed before the layout. The dynamic string table is currently roughly used as follows:

  1. Before layout: Compute the size required for the dynamic string table by iterating over all the dynamic symbols, sonames, DT_NEEDED entries, and so on.
  2. After layout: Again traverse over all the dynamic symbols, so names, DT_NEEDED entries, and this time copy the string into the dynamic string table and carefully assign the string offsets where the strings are referred.

This is cumbersome, error-prone and duplication of work that can be avoided. It is easy to have an inconsistency in iterating over dynamic elements in the Before layout stage or in the After layout stage. It makes things significantly complicated for dynamic sections such as .gnu.version_d and .gnu.version_r where certain offsets inside these sections needs to store offset into the dynamic string table.
@partaror partaror self-assigned this May 16, 2025
partaror pushed a commit to partaror/eld that referenced this issue May 16, 2025
@parth-07
Make dynamic string table simpler to use
d02ae6c 
Currently, dynamic string table is used as follows:

1) Before layout: Compute the size of the dynamic string table by
   traversing over dynamic symbols, sonames, DT_NEEDED entries and so
   on.
2) During output image writing: Again traverse over dynamic symbols,
   sonames, DT_NEEDED entries, ..., This time copy the string into the
   dynamic string table and set the string offset in the dynamic-related
   section that was referring the string.

This separation of computing size, offsets and actually writing makes
the dynamic string table use cumbersome and error-prone. Especially for
sections such as `.gnu.version_r` and `.gnu.version_d`.

With this commit, the dynamic string table can be used as:

```
std::size_t SONameOffset = FileFormat->addStringToDynStrTab(
    llvm::cast<ELFDynObjectFile>(lib)->getSOName());
auto DTEntry = dynamic()->reserveNeedEntry();
DTEntry->setValue(llvm::ELF::DT_NEEDED, SONameOffset);
```

There is no need to separate size and offset computation anymore.

Closes qualcomm#94

Signed-off-by: Parth Arora <partaror@qti.qualcomm.com>
@partaror partaror linked a pull request May 16, 2025 that will close this issue
Open
partaror pushed a commit to partaror/eld that referenced this issue May 16, 2025
@parth-07
Make dynamic string table simpler to use
7a6f8b5 
Currently, dynamic string table is used as follows:

1) Before layout: Compute the size of the dynamic string table by
   traversing over dynamic symbols, sonames, DT_NEEDED entries and so
   on.
2) During output image writing: Again traverse over dynamic symbols,
   sonames, DT_NEEDED entries, ..., This time copy the string into the
   dynamic string table and set the string offset in the dynamic-related
   section that was referring the string.

This separation of computing size, offsets and actually writing makes
the dynamic string table use cumbersome and error-prone. Especially for
sections such as `.gnu.version_r` and `.gnu.version_d`.

With this commit, the dynamic string table can be used as:

```
std::size_t SONameOffset = FileFormat->addStringToDynStrTab(
    llvm::cast<ELFDynObjectFile>(lib)->getSOName());
auto DTEntry = dynamic()->reserveNeedEntry();
DTEntry->setValue(llvm::ELF::DT_NEEDED, SONameOffset);
```

There is no need to separate size and offset computation anymore.

Another added benefit is that now we reuse the `.dynstr` table entries
wherever possible instead of repeating the same string multiple times in
the dynamic string table.

Closes qualcomm#94

Signed-off-by: Parth Arora <partaror@qti.qualcomm.com>
partaror pushed a commit to partaror/eld that referenced this issue May 16, 2025
@parth-07
Make dynamic string table simpler to use
ee8477d 
Currently, dynamic string table is used as follows:

1) Before layout: Compute the size of the dynamic string table by
   traversing over dynamic symbols, sonames, DT_NEEDED entries and so
   on.
2) During output image writing: Again traverse over dynamic symbols,
   sonames, DT_NEEDED entries, ..., This time copy the string into the
   dynamic string table and set the string offset in the dynamic-related
   section that was referring the string.

This separation of computing size, offsets and actually writing makes
the dynamic string table use cumbersome and error-prone. Especially for
sections such as `.gnu.version_r` and `.gnu.version_d`.

With this commit, the dynamic string table can be used as:

```
std::size_t SONameOffset = FileFormat->addStringToDynStrTab(
    llvm::cast<ELFDynObjectFile>(lib)->getSOName());
auto DTEntry = dynamic()->reserveNeedEntry();
DTEntry->setValue(llvm::ELF::DT_NEEDED, SONameOffset);
```

There is no need to separate size and offset computation anymore.

Another added benefit is that now we reuse the `.dynstr` table entries
wherever possible instead of repeating the same string multiple times in
the dynamic string table.

Closes qualcomm#94

Signed-off-by: Parth Arora <partaror@qti.qualcomm.com>
partaror pushed a commit to partaror/eld that referenced this issue May 16, 2025
@parth-07
Make dynamic string table simpler to use
e497dc8 
Currently, dynamic string table is used as follows:

1) Before layout: Compute the size of the dynamic string table by
   traversing over dynamic symbols, sonames, DT_NEEDED entries and so
   on.
2) During output image writing: Again traverse over dynamic symbols,
   sonames, DT_NEEDED entries, ..., This time copy the string into the
   dynamic string table and set the string offset in the dynamic-related
   section that was referring the string.

This separation of computing size, offsets and actually writing makes
the dynamic string table use cumbersome and error-prone. Especially for
sections such as `.gnu.version_r` and `.gnu.version_d`.

With this commit, the dynamic string table can be used as:

```
std::size_t SONameOffset = FileFormat->addStringToDynStrTab(
    llvm::cast<ELFDynObjectFile>(lib)->getSOName());
auto DTEntry = dynamic()->reserveNeedEntry();
DTEntry->setValue(llvm::ELF::DT_NEEDED, SONameOffset);
```

There is no need to separate size and offset computation anymore.

Another added benefit is that now we reuse the `.dynstr` table entries
wherever possible instead of repeating the same string multiple times in
the dynamic string table.

Closes qualcomm#94

Signed-off-by: Parth Arora <partaror@qti.qualcomm.com>
partaror pushed a commit to partaror/eld that referenced this issue May 16, 2025
@parth-07
Make dynamic string table simpler to use
dbb21f1 
Currently, dynamic string table is used as follows:

1) Before layout: Compute the size of the dynamic string table by
   traversing over dynamic symbols, sonames, DT_NEEDED entries and so
   on.
2) During output image writing: Again traverse over dynamic symbols,
   sonames, DT_NEEDED entries, ..., This time copy the string into the
   dynamic string table and set the string offset in the dynamic-related
   section that was referring the string.

This separation of computing size, offsets and actually writing makes
the dynamic string table use cumbersome and error-prone. Especially for
sections such as `.gnu.version_r` and `.gnu.version_d`.

With this commit, the dynamic string table can be used as:

```
std::size_t SONameOffset = FileFormat->addStringToDynStrTab(
    llvm::cast<ELFDynObjectFile>(lib)->getSOName());
auto DTEntry = dynamic()->reserveNeedEntry();
DTEntry->setValue(llvm::ELF::DT_NEEDED, SONameOffset);
```

There is no need to separate size and offset computation anymore.

Another added benefit is that now we reuse the `.dynstr` table entries
wherever possible instead of repeating the same string multiple times in
the dynamic string table.

Closes qualcomm#94

Signed-off-by: Parth Arora <partaror@qti.qualcomm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@partaror partaror

Labels
refactor
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Make dynamic string table simpler to use partaror/eld
1 participant
@partaror
0