Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • FPC Source FPC Source
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 1.4k
    • Issues 1.4k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 84
    • Merge requests 84
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
    • Model experiments
  • External wiki
    • External wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • FPC
  • FPCFPC
  • FPC SourceFPC Source
  • Issues
  • #36144
Closed
Open
Issue created Oct 07, 2019 by FPC Admin account@fpc_adminOwner

Wrong Dwarf2/3/4 info for array (all array, but affects bitpacked) / incorrect use of DW_AT_bit_stride

Original Reporter info from Mantis: Martin @martin_frb
  • Reporter name: Martin Friebe

Description:

for a type like
  TTinyRange = 0..5;
  TBitPackTinyArray     = bitpacked array [0..3] of TTinyRange;

Fpc produces dwarf like

DW_TAG_array_type
  DW_AT_name, DW_FORM_string, 'TBitPackTinyNegArray'+#0
  DW_AT_byte_size, DW_FORM_udata, 2
  DW_AT_type, DW_FORM_ref4, ....
  DW_TAG_subrange_type;
    DW_AT_lower_bound, DW_FORM_sdata, 0
    DW_AT_upper_bound, DW_FORM_sdata, 3
    DW_AT_bit_stride, DW_FORM_udata, 3
    DW_AT_type, DW_FORM_ref4, ....

Note that the stride is in the DW_TAG_subrange_type

Dwarf 2 only allows for stride in DW_TAG_array_type, but not in the subrange at all

Dwarf 3/4 allow for stride in DW_TAG_array_type and DW_TAG_subrange_type
with the following description (from dwarf 4 spec, but same applies in dwarf 3 and 5)

DW_TAG_array_type
If the amount of storage allocated to hold each element of an object of the given array type is different from the amount of storage that is normally allocated to hold an individual object of the indicated element type, then the array type entry has either a DW_AT_byte_stride or a DW_AT_bit_stride attribute, whose value (see Section 2.19) is the size of each element of the array

DW_TAG_subrange_type
If the subrange type occurs as the description of a dimension of an array type, and the stride for that dimension is different than what would otherwise be determined, then the subrange type entry has either a DW_AT_byte_stride or DW_AT_bit_stride attribute which specifies the separation between successive elements along the dimension as described in Section 2.21..

That is a stride in the subrange specifies the amount of PADDING between element (most inner index) or between each sub-array (higher index).

However from the encoded data, fpc intends for the stride to overwrite the element default size.
For this the stride must be in the DW_TAG_array_type
This would then be ok for dwarf 2/3/4 and 5

Mantis conversion info:

  • Mantis ID: 36144
  • OS: win 10
  • OS Build: 10
  • Platform: 64bit Intel
  • Version: 3.3.1
  • Fixed in version: 3.3.1
  • Fixed in revision: 43171 (#6c29ecbd)
  • Monitored by: » @ccrause (Christo Crause)
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking