Opened 13 years ago

Closed 12 years ago

Last modified 10 years ago

#1085 closed task (fixed)

Redesign of the scheme for getting the datacon symbol name of a closure in the RTS

Reported by: mnislaih Owned by:
Priority: normal Milestone: 6.8.1
Component: Runtime System Version: 6.6
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Currently, from the closure we get its info table address, and since those are static for Constr closures, we use a hashtable (defined in Linker.c) to relate symbol names obtained when linking and the addresses.

The proposal is to extend the info table with a field for the symbol name, making this process much more straightforward. The trade-off is that this will augment the size of binaries a bit, so we could make this 'labelling' of info tables optional via a flag.

Change History (8)

comment:1 Changed 13 years ago by mnislaih

Does this explanation make sense?

comment:2 Changed 13 years ago by mnislaih

I wonder if then there would be special versions of the libs compiled under this 'debugging' flag, as currently happens for the profiling libs. Would the increment in size be big enough to justify this inconvenience? Most probably not.

comment:3 Changed 13 years ago by simonmar

No, we definitely don't want to build all the libs twice!

This only affects constructors, so the binary size increase should be minimal. We'll just live with it. Besides, we already derive Data for lots of types, and that instance already contains these strings - perhaps we could arrange to share them?

The right way is to make a new kind of info table for constructors, just as we currently have StgFunInfoTable for functions, and StgRetInfoTable for return addresses. The constructor info table would have a single extra field, containing a pointer to the name of the constructor (in UTF-8, of course).

comment:4 Changed 12 years ago by simonmar

Resolution: fixed
Status: newclosed

This is now done.

comment:5 Changed 12 years ago by igloo

Milestone: 6.8 branch6.8.1

comment:6 Changed 11 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:7 Changed 11 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:8 Changed 10 years ago by simonmar

difficulty: Moderate (1 day)Moderate (less than a day)
Note: See TracTickets for help on using tickets.