coffread.c extension for DLLs without debugging symbols

coffread.c extension for DLLs without debugging symbols

[Raoul Gough]

Patch for coffread.c to extract minimal symbolic information from a
portable executable using the export table. This provides a fallback
for DLLs without any gdb-recognized debugging symbols
(e.g. kernel32.dll). The export table read algorithm is taken from
pe-dll.c from the ld sources.

Actually, I'm surprised this hasn't been added before, because it
seems pretty handy to have. This is my *first* gdb patch submission,
so someone with more experience should probably take a good look at
(e.g. is coffread.c the right place for this kind of code?). I've
compiled and tested it on Windows 2000 using Cygwin (where it works)
and on i386 Suse Linux (where it compiles and remains politely
inactive).

Bugs: Using dll-symbols or symbol-file on a DLL that has already had
its export table loaded results in multiple copies of all of the
symbols. Also, gdb seems to dereference all minimal symbols as if they
were pointers, so you often need to add an "&" to the symbol names.

Proposed ChangeLog entry, assuming the code is accepted:

2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>

 * coffread.c: Support non-debug export symbols for win32 DLLs


See the example for a simple demonstration of what the new code can
do. The code amounts to about 350 lines, so I'm not sure if this would
require me to fill out a copyright form.

Regards,
Raoul Gough.


begin 666 coffread.c.diff.gz
M'XL("(S5%3X"`V-O9F9R96%D+F,N9&EF9@"U&FEOVT;VLX/F/[QZL;'NZ# <
M)XH-N+%WX6V:%+%W6VS6("AR)+&F."J']-'4_WW?FXM#BI23M!5@F<>\-^^^
M1N=)R.Y>0<#G\Y3YX2!X^N3HCW^>/OGPY@+F4<Q>P?/@1CP7:2#_%N'L>;%7
M[^;IDY1E:<1NHF0!*?X3$4]@-)B,GSX)H_D<^@'TU]!/Z5&)RDZGX]SOC%[ 
M*0M@/!R.83A\-7GY:O@"^D/\["AL_7[?73^!?_D)+9_ Z/#5>!\AU'*)V?V 
MR/PL"N"&1R$0M,<3YHG[%;1$EN9!)M'B`T73Z,7+WNAP'PA4[:J>' !>]Y\^
M`=C9V0'0H%&2L33Q8\+'D@PZ/<@3$H%]X>=W\D5[2K#TY]*CMUYE_LPCVJ 5
M\V1!2$2T2%A(>'IF,S[[A52B<'6!_C9X6S./W:UYFK&0\ K+I 76%XJ>;^CK
M>0=^8N"G# (_CG%3G@0,UBP%P8*,N)FG?&5I)6A)[ `0CA#@)V$(EW%@=_XJ
M2A@P/UA:\%N%?>T+P<(>!$L67--BP=BFNNI%`OH)OA0L(P%I=0T/#WJCX<N1
MJ[#AX6%OA \+E3UH,N%!::&+E]$<6JU$"NGH"(9M>/8,6B@_*9VV6@/PR5QH
M.>W=,%CP#!(.(9OEBT6DB)OQ6/1@EF=PG?!;6.(?<B@9R)8,XDADA&D'^!R,
MA@P<M,AB)FAC?@8Q\T76'L E0@4\9."MHL4R\^"6I]<:10(<D:8HU6 992CE
M/&5Z]Z4ODKT,9HPED#&!NPS@C1+XDBGPS$\7##GP5XQHG#%"2$0*?XY?$>[9
M>6XL3'V"I9\B-8E 2];@1S";AQY>>?I!2UM6_YCCF\)&U4=*&VTQ"59K:"F0
M'NRN69\8W^W!I*W4H&B$WW^'VN616;^OURN 3QJLP0D<H^]*:^@::^B",@VB
M+T;)>X+G::"MP%B-M$F6A-HN2_C(G*HV7 XS*5N@]LF=2O$&5:]M>'2 -CQZ
M4;)AC$&]T?[A86'#`#/$>SW=,.BN^OJ&OM!&3\(P(K?S8^N 43+GZ<J7URD+
M>!JB\?V2HS;QN53].D_77#"!YBF%TVF09&$8FAFS3&_EA7[FTVOM-V_>?SCS
M3DY//\#-RM?>.X7R!VE^+U^0-<;<)^+\,$23)G(L$VIK*&*CC OIC>]A%$S+
M6!'E!3T$M2/<1MDR4D:^9ELPH8ZG&\2=)>%V/"S)5X!A+UJI3( ^[67WN& E
MY/^IPG-)CY!%#(.XK75^Q%=F\<&ZSM]"-J=H^N.9=W'VYO+\_3OO_-WIV<_>
MY=G/EY*\X=9EIR>7)W+9:.NR[RXN%+/CAF67)]^]Q;OS_Y[)99.MV,[?_>?D
M[?DI]$>&#>3]GZ1=E%I$]0IIE6XH`H6.D0*Z'O#;!.-:ZM_WX'8981;!L)/Y
M42*T76;L#B,!F1GXJ)B9D!+,EA@ZR:[3`7Q@& ^31L(T'G1XE9 0#5H"N<4B
MB81#D R02B4ZSV(VWC!XQ5%+!4<9)SOF%2%H.\Y ,0;=1H8T=PT&M@&QM>N$
MP$KN21MX(D.85L*9-,E8L*W[D0"_8C^RJ*_:#_7T%=NA93;M]@58M.++F!X<
MZ_P@8Z*TR9LHS7(,G2NVXNF]&X?\BINZM1>E0<,Q!CK,.)@"H>/C=P_]W<#1
MQ;JG0#IDUZATUT"VQ%1K55BM@ ;5#)%5RI=W^*K!/.7._6-ID4YFEAI3H-\>
M-0JNH1@Z);*<B&C8E.&82AD;FZ&(F>2S?E;@04\T=80CP%;;(%9Z&& XYUA"
M$A(=BJLEBA'/1\7/U:!(.#+I']7M`RVE(BF>-O0WL13Y9=-Z3,9]@T+/D#63
M`W1HQ[R0H0E1BL404RGZ-HV(;M'<JCD70XL**O<KY4R2FQU)2CF!S?,D\)!>
M=X4*2Y]C5_)N$U1M'L;QQN9-C85CSZH:4<9!^K-Y%+/@0F>$S80OE[M"JI01
M:.6&5>B"2W[_V*DR%*2B_U=TZ6@>H41E4,<HY/B.8<Z+L68^(K[HHF4>MYVE
M`<^3S/$?F=D2EBKUMY9\S>9Y'-]3%_AKSMI@-U;9)!?4+A"#\RA%Z:[1L+1=
M=0SKN"^HJ,D&BP%\?_;AW=G;R?A;E.1)QE<GU!I$`K"<PT9*:.'>Q\SBR2F)
MS>[1@Y)PME#-&ZW:_2$*4B[X/,->V[0NEYQJ$++1GW YOQ6[)<_:$-P=VG?,
M@T(\4FI=*S5CIFU\-G9#C2SFU_?0*J/L6?'W2HHP4B^O_N@NN4)R]K[=FUK\
M->B1B@JAHQY8&AWR5%GLE:NX#6*5^>^0%=KKL@'JDL^^+74>:JN[><I8%76[
M;%5G-#]0,3/&XD=9#^:56Q;'IC"2?2$VHM3M:8.S#M/ 3B6(?#4C;O*\3-$9
ME0,845/P+XP\Y"J,^ 'QM)D\35C*-"*%HE6./&Y80?8QX+3*[RKY2?:;Q0JJ
M//8&>^5FT;XF0_K?<&]*[!@JA$Q5@9]35Q1SOL8('IFTL_-03CZF(+&HNUV#
MNZ[E+&6/M]AU]C'V8<0'D:\I\DM_;"4\Z<L90]OV"C:)2*>F:W^F/;^#+UF0
MRP>BIX+ [9+)Q)NJ`4S"]=Q %[N_%2.(`;SAH4&$9DE[M"@%PXJ':*6!;!Y%
M6V_,^LC>(%!W<5AJ"Z5BW0$6/4;U8L ?'9B$>TM$6;V!K99LEI7A5JZ:.IJW
M:*5QS#Z.KQRWH?PN&+LV>[3DI&J=I6V%J <79V??8XES:8(+0<S4D&G6DS6;
M)U JTO#;,,;2S4XR;'4Y^SB\PC#2FGT<7<'KUW!8\8BM`IB,_V0![/^5`MC_
M3 &HN[&\&QWHVXF\'>]_MGA\0=(A:JT(5*&,CYI%T)FA\YH5?R*=LBO0PSO7
M$Y4'FOI$>IOR`K_9'0> K6F$Z=:GTL#F8_0;JF-DS8S\1ZMU3-D`_R,B#QU,
M(RJ[W(:K?<WPUQ&GM#RJ.8Z@-,";ULU(<(<E[L12.XCEZVP9TBW&G"1?>53S
M1A2 HEH$BCY9I9IK,CB$-96W+,91H?*]46P-&H]D-\/>:EIK%KA"%K1XA9O5
M(I%%`;[$+3%7DG:(!P24]P[J<B8J)^H3&E5@_&<T_Q<RS,J9VB-3"FOBYTF4
M15@(_*:F<S+DRGY#EK?'0%-'NEKDF$"Q*) 5G]- Y4GNS"RP0.!J_*OKP]!6
M!-MZ`/?F8^W<Y\IL> 2?X-.P1V44?J]$YA&K#ZI,*+\@;+4O4!H/SI3+TA;$
MS$_R-?JT'UQ[V".8.MTIMK/"!J7QJ4&G>B!%C48X8ZDHYNR@31*]T,BB:L84
M0FQ\#JG"&MY-`A/W"A-7Z\J@7=BG4M<T%(X/;&)U,'7AY;C:B;NP&*':Q/$[
MKMEPZ:^9>M2.2:RS/4;*@>'5\<E'8$;#H0%*G-%$D>@E2).X#*CR=81K-0H6
MNKJF@L]$CJ'=84>AK[$C"L$D&C(:R:_NOTR$5SQ)J6M 695%$AM$J"'+-]YV
MNW55J(P<0G8NAU=%:J\$(B6$$?6>2AS(QY!&E(T0-]0N;RK(($(96 G7`-=K
MUP$^: :>*WDVPHZ'U9.?HBJ12YVB1$-MEB50+DV$:@^KY<FA[!CK#IJ4>%X?
MN1[P[)F66E<+X-AY6^X+K-7,E3):#IJ^PJ)/DM1VSNMNR8..RUNVK2&7W4S1
MT]^ZCSG[J3F^,N&CA+1AT$JMY6J=W1LK5P5,$5>VA1,Z5 G\I,@UTG/L7(X2
MYH8SI9@9;_PD*X#,7E_N3'_8:1ZS^\/V7^-P\]A?B&W DY+#J:#!`C7Q>.G&
MC6+4.]V8?GHZS)AF]@L\$$D8/NZ%>HO/=<3/&$EO3#[@RV;2UF-+!<S&Z)9<
MC/0W?6PU%EMFK?'99I?3%2;EKDKMV2ZF9(Y/VI[+%C<K_YIYINAIR;%0SZ!M
MU_9U5?VI2+6UK[.%<%5KI?+;Z@_Y4O6"8:_OA$F')JJ3E4FKOLTL[]I6"HH"
MNW[AQ+J,*;\;UATXZV24J5TV<HL8VQTTT'A8F;?]FXZO]&]V[ 06GXB,A(C!
MC,:ZL/:SI7,J". ,D.HH&E./R<J"(RVL_+7';[!NL5%1:;9ZC-0KF:I+\CI%
M:N?T*P6DF68UNS^4SAZ$ZAK_+@:#P6XQ6342NDV1`CD7:NWN5D1AYWEFDE=,
M\>CP6K:;ZY1CWL .4_8K%.CM--,Z,H'3P!*Y4A/R`5PL>8Y=[\J_QP8%]<WI
MD 'EH#"C@&-^BV5\X!?'>S)/R%5)Q.AW2=@DZ4FU,^RL'2"6F;;\G6=J7I\M
M4YXOEO;G.?*W!F8:UIRF4+V-&0JQ_\@C-;KE]HA;P UJD:>E`KZI&2U9DJHH
M"C?J(@D=V*]&S,UM[5S!'*LX%$!CFC*'*ILDE#RJF8I_H&)P_TAH0>Z)QM/]
MDBA*)YC#"EZI`>>M6?FZ_A<*4^AVU8IRBI #8<OB\=$C.:.HU4#^,,Q"OMZ:
M/MH%W"<'0^VY7D6]9M).()6C//FLU+'K<Z\[=T'ED$X^*__P2>?THI2T*:TV
MPZ%&PT@$?AK:;& #'S>)B\ZZ5493OX9Z<']7>.',L[')EX=?LN)<8J$8TRTA
*_#]BK%JOQ2H`````
`
end

begin 666 example.txt
M)"!C870@9&QL96<N8PT*7U]A='1R:6)U=&4H*%]?9&QL97AP;W)T7U\I*2!V
M;VED(&9N("@I('L@?0T*#0I?7V%T=')I8G5T92@H7U]D;&QE>'!O<G1?7RDI
M(&-H87(@:&5L;&];72 ](")(96QL;R!W;W)L9"([#0H-"E]?871T<FEB=71E
M*"A?7V1L;&5X<&]R=%]?*2D@:6YT(&EN:71?9&%T82 ](#0R.PT*#0I?7V%T
M=')I8G5T92@H7U]D;&QE>'!O<G1?7RDI(&EN="!U;FEN:71?9&%T83L-"@T*
M)"!C870@9&QL96=M86EN+F,-"E]?871T<FEB=71E*"A?7V1L;&EM<&]R=%]?
M*2D@=F]I9"!F;B H*3L-"@T*7U]A='1R:6)U=&4H*%]?9&QL:6UP;W)T7U\I
M*2!C:&%R(&AE;&QO6UT[#0H-"E]?871T<FEB=71E*"A?7V1L;&EM<&]R=%]?
M*2D@:6YT(&EN:71?9&%T83L-"@T*7U]A='1R:6)U=&4H*%]?9&QL:6UP;W)T
M7U\I*2!I;G0@=6YI;FET7V1A=&$[#0H-"FEN="!M86EN("@I#0I[#0H@(&9N
M*"D[#0H@('5N:6YI=%]D871A(#T@:6YI=%]D871A.PT*#0H@(')E='5R;B P
M.PT*?0T*)"!G8V,@+6,@9&QL96<N8PT*)"!G8V,@+6,@9&QL96=M86EN+F,-
M"B0@(PT*)" C($YO=&4Z("U7;"PM<R!S=')I<',@86QL('!O<W-I8FQE('-Y
M;6)O;',-"B0@(PT*)"!G8V,@+5=L+"US("US:&%R960@+6\@9&QL96<N9&QL
M(&1L;&5G+F\-"B0@9V-C("U7;"PM<R M;R!D;&QE9VUA:6X@9&QL96=M86EN
M+F\@9&QL96<N9&QL#0HD(&=D8B!D;&QE9VUA:6X-"D=.52!G9&(@,C P,RTP
M,2TP,2UC=G,-"D-O<'ER:6=H=" R,# R($9R964@4V]F='=A<F4@1F]U;F1A
M=&EO;BP@26YC+@T*1T1"(&ES(&9R964@<V]F='=A<F4L(&-O=F5R960@8GD@
M=&AE($=.52!'96YE<F%L(%!U8FQI8R!,:6-E;G-E+"!A;F0@>6]U(&%R90T*
M=V5L8V]M92!T;R!C:&%N9V4@:70@86YD+V]R(&1I<W1R:6)U=&4@8V]P:65S
M(&]F(&ET('5N9&5R(&-E<G1A:6X@8V]N9&ET:6]N<RX-"E1Y<&4@(G-H;W<@
M8V]P>6EN9R(@=&\@<V5E('1H92!C;VYD:71I;VYS+@T*5&AE<F4@:7,@86)S
M;VQU=&5L>2!N;R!W87)R86YT>2!F;W(@1T1"+B @5'EP92 B<VAO=R!W87)R
M86YT>2(@9F]R(&1E=&%I;',N#0I4:&ES($=$0B!W87,@8V]N9FEG=7)E9"!A
M<R B:38X-BUP8RUC>6=W:6XB+BXN*&YO(&1E8G5G9VEN9R!S>6UB;VQS(&9O
M=6YD*2XN+@T**&=D8BD@8G)E86L@;6%I;@T*3F\@<WEM8F]L('1A8FQE(&ES
M(&QO861E9"X@(%5S92!T:&4@(F9I;&4B(&-O;6UA;F0N#0HH9V1B*2 C#0HH
M9V1B*2 C(%)U;B!T:&4@<')O9W)A;2!T;R!G970@86QL($1,3',@;&]A9&5D
M+B!4:&4@;F5W(&-O9&4-"BAG9&(I(",@97AT<F%C=',@=&AE(&5X<&]R=&5D
M('-Y;6)O;',@9G)O;2!T:&4@1$Q,<PT**&=D8BD@(PT**&=D8BD@<G5N#0I3
M=&%R=&EN9R!P<F]G<F%M.B O8WEG9')I=F4O9B]5<V5R<R]286]U;"]G9&(O
M9&QL96=M86EN+F5X92 -"@T*4')O9W)A;2!E>&ET960@;F]R;6%L;'DN#0HH
M9V1B*2 C#0HH9V1B*2 C($-A;B!N;W<@<V5T(&$@8G)E86MP;VEN="!A;F0@
M<F5S=&%R="!T:&4@<')O9W)A;2X-"BAG9&(I(",@57-E("HF('1O(&)Y<&%S
M<R!E;G1R>2!P;VEN="!D971E<FUI;F%T:6]N("AS964-"BAG9&(I(",@86QS
M;R!087-C86P@3V)R>2=S(&DS.#8M=&1E<"YC('!A=&-H(&9O<B!G9&(-"BAG
M9&(I(",@<')O8FQE;2!R97!O<G0@-S@P*0T**&=D8BD@(PT**&=D8BD@8G)E
M86L@*B9F;@T*0G)E86MP;VEN=" Q(&%T(#!X,3 P,#$P,# -"BAG9&(I(')U
M;@T*4W1A<G1I;F<@<')O9W)A;3H@+V-Y9V1R:79E+V8O57-E<G,O4F%O=6PO
M9V1B+V1L;&5G;6%I;BYE>&4@#0H-"D)R96%K<&]I;G0@,2P@,'@Q,# P,3 P
M,"!I;B!F;B H*2!F<F]M("]C>6=D<FEV92]F+U5S97)S+U)A;W5L+V=D8B]D
M;&QE9RYD;&P-"BAG9&(I(",-"BAG9&(I(",@2&ET('1H92!B<F5A:W!O:6YT
M(2!7:71H;W5T('1H92!P871C:"P@9V1B(&1O97-N)W0-"BAG9&(I(",@<F5P
M;W)T(&%N>2!O9B!S>6UB;VQI8R!N86UE<R!I;B!T:&4@9F]L;&]W:6YG#0HH
M9V1B*2 C('-T86-K('1R86-E.@T**&=D8BD@(PT**&=D8BD@=VAE<F4-"B,P
M(" P>#$P,# Q,# P(&EN(&9N("@I(&9R;VT@+V-Y9V1R:79E+V8O57-E<G,O
M4F%O=6PO9V1B+V1L;&5G+F1L; T*(S$@(#!X-C$P,#-F-#(@:6X@8WEG=VEN
M,2%?7V%S<V5R=" H*0T*(S(@(#!X-C$P,#0R,S8@:6X@9&QL7V-R=#! ," H
M*0T*(S,@(#!X-C$P,#0R-S4@:6X@9&QL7V-R=# @*"D-"B,T(" P># P-# Q
M,&)F(&EN(#\_("@I#0HC-2 @,'@P,#0P,3 S9"!I;B _/R H*0T*(S8@(#!X
M-S=E.3DR838@:6X@2T523D5,,S(A1V5T0V]M;6%N9$QI;F57("@I#0HH9V1B
M*2 C#0HH9V1B*2 C($%C8V5S<VEN9R!D871A(&-A;B!B92!A(&)I="!T<FEC
M:WD@8F5C875S92!T:&5R92!I<PT**&=D8BD@(R!N;R!T>7!E(&EN9F]R;6%T
M:6]N#0HH9V1B*2 C#0HH9V1B*2!P<FEN="!I;FET7V1A=&$-"B0Q(#T@-#(-
M"BAG9&(I('!R:6YT("AC:&%R("HI)FAE;&QO#0HD,B ](#!X,3 P,#(P,# @
M(DAE;&QO('=O<FQD(@T**&=D8BD@>"]S("9H96QL;PT*,'@Q,# P,C P," \
M:&5L;&\^.@D@(DAE;&QO('=O<FQD(@T**&=D8BD@>"]X("9I;FET7V1A=&$-
M"C!X,3 P,#(P,&,@/&EN:71?9&%T83XZ"3!X,# P,# P,F$-"BAG9&(I('@O
M>" F=6YI;FET7V1A=&$-"C!X,3 P,#,P9F,@/'5N:6YI=%]D871A/CH),'@P
M,# P,# P, T**&=D8BD@(PT**&=D8BD@(R!1=6%L:69I960@;F%M97,@=7-U
M86QL>2!N965D('%U;W1E<R!T;R!W;W)K('!R;W!E<FQY+@T**&=D8BD@(R!4
M:&5S92!M87D@8F4@=7-E9G5L('-O;65T:6UE<R!T;R!R97-O;'9E(&YA;64@
M8VQA<VAE<PT**&=D8BD@(R!O<B!W:&5N(&QI<W1I;F<@86QL('-Y;6)O;',@
M9G)O;2!A($1,3"X-"BAG9&(I(",-"BAG9&(I('@O>" F)V1L;&5G(6EN:71?
M9&%T82<-"C!X,3 P,#(P,&,@/&EN:71?9&%T83XZ"3!X,# P,# P,F$-"BAG
M9&(I(&EN9F\@=F%R:6%B;&5S(&1L;&5G(0T*06QL('9A<FEA8FQE<R!M871C
M:&EN9R!R96=U;&%R(&5X<')E<W-I;VX@(F1L;&5G(2(Z#0H-"DYO;BUD96)U
M9V=I;F<@<WEM8F]L<SH-"C!X,3 P,#(P,# @(&1L;&5G(6AE;&QO#0HP>#$P
M,# R,#!C("!D;&QE9R%I;FET7V1A=&$-"C!X,3 P,#,P9F,@(&1L;&5G(75N
M:6YI=%]D871A#0HH9V1B*2!I;F9O(&9U;F-T:6]N<R!D;&QE9R$-"D%L;"!F
M=6YC=&EO;G,@;6%T8VAI;F<@<F5G=6QA<B!E>'!R97-S:6]N(")D;&QE9R$B
M.@T*#0I.;VXM9&5B=6=G:6YG('-Y;6)O;',Z#0HP>#$P,# Q,# P("!D;&QE
M9R%F;@T**&=D8BD@(PT**&=D8BD@(R!0<F]B;&5M(&AE<F4@:7,@=&AA="!S
M>6UB;VPM9FEL92!R96QO861S('1H92 J<V%M92H@<WEM8F]L<PT**&=D8BD@
M(R!A;F0@8W)E871E<R!D=7!L:6-A=&4@;6EN:6UA;"!S>6UB;VP@96YT<FEE
M<PT**&=D8BD@(PT**&=D8BD@<WEM8F]L+69I;&4@9&QL96<N9&QL#0I296%D
M:6YG('-Y;6)O;',@9G)O;2!D;&QE9RYD;&PN+BY-:6YI;6%L('-Y;6)O;',@
M9G)O;2!D;&QE9RYD;&PN+BX-"BAN;R!D96)U9V=I;F<@<WEM8F]L<R!F;W5N
M9"DN+BYD;VYE+@T**&=D8BD@:6YF;R!F=6YC=&EO;G,@2T523D5,,S(N*@T*
M06QL(&9U;F-T:6]N<R!M871C:&EN9R!R96=U;&%R(&5X<')E<W-I;VX@(DM%
M4DY%3#,R+BHB.@T*#0I.;VXM9&5B=6=G:6YG('-Y;6)O;',Z#0HP>#<W93@Q
M-68V("!+15).14PS,B%)<T1E8G5G9V5R4')E<V5N= T*,'@W-V4X,38P-" @
M2T523D5,,S(A3W5T<'5T1&5B=6=3=')I;F=7#0HP>#<W93@Q-C9E("!+15).
M14PS,B%7<FET95!R;V9I;&5396-T:6]N00T*,'@W-V4X,38X," @2T523D5,
M,S(A1V5T4')O9FEL95-E8W1I;VY7#0HP>#<W93@Q-CDV("!+15).14PS,B%7
M<FET95!R:79A=&50<F]F:6QE4V5C=&EO;D$-"C!X-S=E.#$V8F8@($M%4DY%
L3#,R(4=E=%!R:79A=&50<F]F:6QE4V5C=&EO;E<-"@T*6V5T8RXN+BY=#0H`
`
end

Re: coffread.c extension for DLLs without debugging symbols

[Michael Snyder]

Raoul Gough wrote:
> 
> Patch for coffread.c to extract minimal symbolic information from a
> portable executable using the export table. This provides a fallback
> for DLLs without any gdb-recognized debugging symbols
> (e.g. kernel32.dll). The export table read algorithm is taken from
> pe-dll.c from the ld sources.
> 
> Actually, I'm surprised this hasn't been added before, because it
> seems pretty handy to have. This is my *first* gdb patch submission,
> so someone with more experience should probably take a good look at
> (e.g. is coffread.c the right place for this kind of code?). I've
> compiled and tested it on Windows 2000 using Cygwin (where it works)
> and on i386 Suse Linux (where it compiles and remains politely
> inactive).

Well, without having evaluated your code for correctness,
I think it's a well-done change.  And I think coffread.c
is the right place for it.  You don't change the behavior
except in the specific case you're interested in (and the
behavior can't get much worse than not having any symbols), 
so I'd recommend this for acceptance.  But Phillipe is the
coff reader maintainer.

> 
> Bugs: Using dll-symbols or symbol-file on a DLL that has already had
> its export table loaded results in multiple copies of all of the
> symbols. Also, gdb seems to dereference all minimal symbols as if they
> were pointers, so you often need to add an "&" to the symbol names.
> 
> Proposed ChangeLog entry, assuming the code is accepted:
> 
> 2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>
> 
>  * coffread.c: Support non-debug export symbols for win32 DLLs
> 
> See the example for a simple demonstration of what the new code can
> do. The code amounts to about 350 lines, so I'm not sure if this would
> require me to fill out a copyright form.
> 
> Regards,
> Raoul Gough.
> 
>                          Name: coffread.c.diff.gz
>    coffread.c.diff.gz    Type: unspecified type (application/octet-stream)
>                      Encoding: x-uuencode
> 
> $ cat dlleg.c
> __attribute((__dllexport__)) void fn () { }
> 
> __attribute((__dllexport__)) char hello[] = "Hello world";
> 
> __attribute((__dllexport__)) int init_data = 42;
> 
> __attribute((__dllexport__)) int uninit_data;
> 
> $ cat dllegmain.c
> __attribute((__dllimport__)) void fn ();
> 
> __attribute((__dllimport__)) char hello[];
> 
> __attribute((__dllimport__)) int init_data;
> 
> __attribute((__dllimport__)) int uninit_data;
> 
> int main ()
> {
>   fn();
>   uninit_data = init_data;
> 
>   return 0;
> }
> $ gcc -c dlleg.c
> $ gcc -c dllegmain.c
> $ #
> $ # Note: -Wl,-s strips all possible symbols
> $ #
> $ gcc -Wl,-s -shared -o dlleg.dll dlleg.o
> $ gcc -Wl,-s -o dllegmain dllegmain.o dlleg.dll
> $ gdb dllegmain
> GNU gdb 2003-01-01-cvs
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i686-pc-cygwin"...(no debugging symbols found)...
> (gdb) break main
> No symbol table is loaded.  Use the "file" command.
> (gdb) #
> (gdb) # Run the program to get all DLLs loaded. The new code
> (gdb) # extracts the exported symbols from the DLLs
> (gdb) #
> (gdb) run
> Starting program: /cygdrive/f/Users/Raoul/gdb/dllegmain.exe
> 
> Program exited normally.
> (gdb) #
> (gdb) # Can now set a breakpoint and restart the program.
> (gdb) # Use *& to bypass entry point determination (see
> (gdb) # also Pascal Obry's i386-tdep.c patch for gdb
> (gdb) # problem report 780)
> (gdb) #
> (gdb) break *&fn
> Breakpoint 1 at 0x10001000
> (gdb) run
> Starting program: /cygdrive/f/Users/Raoul/gdb/dllegmain.exe
> 
> Breakpoint 1, 0x10001000 in fn () from /cygdrive/f/Users/Raoul/gdb/dlleg.dll
> (gdb) #
> (gdb) # Hit the breakpoint! Without the patch, gdb doesn't
> (gdb) # report any of symbolic names in the following
> (gdb) # stack trace:
> (gdb) #
> (gdb) where
> #0  0x10001000 in fn () from /cygdrive/f/Users/Raoul/gdb/dlleg.dll
> #1  0x61003f42 in cygwin1!__assert ()
> #2  0x61004236 in dll_crt0@0 ()
> #3  0x61004275 in dll_crt0 ()
> #4  0x004010bf in ?? ()
> #5  0x0040103d in ?? ()
> #6  0x77e992a6 in KERNEL32!GetCommandLineW ()
> (gdb) #
> (gdb) # Accessing data can be a bit tricky because there is
> (gdb) # no type information
> (gdb) #
> (gdb) print init_data
> $1 = 42
> (gdb) print (char *)&hello
> $2 = 0x10002000 "Hello world"
> (gdb) x/s &hello
> 0x10002000 <hello>:      "Hello world"
> (gdb) x/x &init_data
> 0x1000200c <init_data>: 0x0000002a
> (gdb) x/x &uninit_data
> 0x100030fc <uninit_data>:       0x00000000
> (gdb) #
> (gdb) # Qualified names usually need quotes to work properly.
> (gdb) # These may be useful sometimes to resolve name clashes
> (gdb) # or when listing all symbols from a DLL.
> (gdb) #
> (gdb) x/x &'dlleg!init_data'
> 0x1000200c <init_data>: 0x0000002a
> (gdb) info variables dlleg!
> All variables matching regular expression "dlleg!":
> 
> Non-debugging symbols:
> 0x10002000  dlleg!hello
> 0x1000200c  dlleg!init_data
> 0x100030fc  dlleg!uninit_data
> (gdb) info functions dlleg!
> All functions matching regular expression "dlleg!":
> 
> Non-debugging symbols:
> 0x10001000  dlleg!fn
> (gdb) #
> (gdb) # Problem here is that symbol-file reloads the *same* symbols
> (gdb) # and creates duplicate minimal symbol entries
> (gdb) #
> (gdb) symbol-file dlleg.dll
> Reading symbols from dlleg.dll...Minimal symbols from dlleg.dll...
> (no debugging symbols found)...done.
> (gdb) info functions KERNEL32.*
> All functions matching regular expression "KERNEL32.*":
> 
> Non-debugging symbols:
> 0x77e815f6  KERNEL32!IsDebuggerPresent
> 0x77e81604  KERNEL32!OutputDebugStringW
> 0x77e8166e  KERNEL32!WriteProfileSectionA
> 0x77e81680  KERNEL32!GetProfileSectionW
> 0x77e81696  KERNEL32!WritePrivateProfileSectionA
> 0x77e816bf  KERNEL32!GetPrivateProfileSectionW
> 
> [etc....]

Re: coffread.c extension for DLLs without debugging symbols

[Christopher Faylor]

On Fri, Jan 03, 2003 at 07:39:31PM -0000, Raoul Gough wrote:
>Proposed ChangeLog entry, assuming the code is accepted:
>
>2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>
>
> * coffread.c: Support non-debug export symbols for win32 DLLs

WONDERFUL! I would love to have this code in the windows version of gdb.
I've often thought about doing something like this but I've never had
the stamina to look into what it would take to do this.

I have a few comments.

0) The ChangeLog needs more information.  Every new function should be
mentioned and changes to specific functions should be documented.

1) AFAICT, the formatting of the code looks great (a rarity for a first
timer) except for an odd comment or two which doesn't end in a "." as
required for a complete sentence.  Yeah, yeah, a total nit but hey we've
got standards!

2) I wonder if this code should be ifdef'ed somehow for Windows since
it will add extra code for no gain on every COFF platform.  Of course,
how many of those are there out there?  Maybe this isn't a huge issue
after all.

3) objdump -p already has the ability to read and report on the export
table.  I wonder if it would be useful (or possible) to generalize this
code so that gdb and objdump would be using the same base.  I haven't
looked too closely but I think the code in question is in bfd/peicode.h.
Hmm.  Maybe objdump isn't interested in the kinds of things that gdb
is, though, like what section a symbol is associated with...

Anyway, I'll be giving this an actual test run in the next couple of
days.  In the meantime, THANK YOU for doing this.  Even given the very
minor above points, I think this will be a great boon for the Windows
version of gdb.  This will help enormously in debugging on Windows.

You will definitely need to get an assignment in to the FSF, though,
unfortunately.  I think jimb at redhat dot com is the person to help
you with that.

cgf

P.S.  Assuming that this works as advertised, I assume that you will
have no objections to my releasing a new version of gdb for windows
with this patch in it before the patch makes its way into the official
gdb repository, right?  I think there are a few users in the cygwin
mailing list that would appreciate this change.
--
Special for spam email harvesters: send email to aaaspam@sources.redhat.com
and be permanently blocked from mailing lists at sources.redhat.com.

Re: coffread.c extension for DLLs without debugging symbols

[Eli Zaretskii]

> From: "Raoul Gough" <RaoulGough@yahoo.co.uk>
> Date: Fri, 3 Jan 2003 19:39:31 -0000
> 
> This is my *first* gdb patch submission,
> so someone with more experience should probably take a good look at
> (e.g. is coffread.c the right place for this kind of code?).

Lesson number 1: post the diffs as plain text, not uuencoded or
otherwise encoded.  Some people, such as myself, don't have time to
open binary attachments, but do have time to read a patch that's in
plain text.

Also, please include "[RFA]" in the subject, so that we know you are
seeking an approval for your patch.

> Proposed ChangeLog entry, assuming the code is accepted:
> 
> 2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>
> 
>  * coffread.c: Support non-debug export symbols for win32 DLLs

This should mention every function where changes are made, preferably
with a description of a change in each one of them.

And thanks for working on this.

Re: coffread.c extension for DLLs without debugging symbols

[Raoul Gough]

"Eli Zaretskii" <eliz@is.elta.co.il> wrote in message
news:2110-Sat04Jan2003130101+0200-eliz@is.elta.co.il...
> > From: "Raoul Gough" <RaoulGough@yahoo.co.uk>
> > Date: Fri, 3 Jan 2003 19:39:31 -0000
> >
> > This is my *first* gdb patch submission,
> > so someone with more experience should probably take a good look
at
> > (e.g. is coffread.c the right place for this kind of code?).
>
> Lesson number 1: post the diffs as plain text, not uuencoded or
> otherwise encoded.  Some people, such as myself, don't have time to
> open binary attachments, but do have time to read a patch that's in
> plain text.

OK, point taken. I was assuming that it was better to reduce some
bandwidth, given the size of the patch (circa 10kB). OK, you can all
laugh at me now for being so bandwidth-challenged that I still think
about that stuff :-)

>
> Also, please include "[RFA]" in the subject, so that we know you are
> seeking an approval for your patch.

What does RFA stand for? Seemed to me like it was used by people who
were actually capable of updating the CVS themselves and just wanted
confirmation.

>
> > Proposed ChangeLog entry, assuming the code is accepted:
> >
> > 2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>
> >
> >  * coffread.c: Support non-debug export symbols for win32 DLLs
>
> This should mention every function where changes are made,
preferably
> with a description of a change in each one of them.

Done! See my reply to Christopher Faylor on the patches mailing list.

>
> And thanks for working on this.

No problem - hope it's useful to some people.

Regards,
Raoul Gough.

Re: coffread.c extension for DLLs without debugging symbols

[Raoul Gough]

"Christopher Faylor" <cgf@redhat.com> wrote in message
news:20030104044408.GA7364@redhat.com...
> On Fri, Jan 03, 2003 at 07:39:31PM -0000, Raoul Gough wrote:
> >Proposed ChangeLog entry, assuming the code is accepted:
> >
> >2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>
> >
> > * coffread.c: Support non-debug export symbols for win32 DLLs
>
> WONDERFUL! I would love to have this code in the windows version of
gdb.
> I've often thought about doing something like this but I've never
had
> the stamina to look into what it would take to do this.
>
> I have a few comments.
>
> 0) The ChangeLog needs more information.  Every new function should
be
> mentioned and changes to specific functions should be documented.

How's this:

2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>

 * coffread.c: Support non-debug export symbols for win32 DLLs.
 (coff_symtab_read): call read_pe_exported_syms iff no symbols
 found and objfile is "pe-i386" or "pei-i386".
 (read_pe_exported_syms): New function.
 (read_pe_section_data): New struct (temporary section info).
 (read_pe_section_index): New function.
 (read_pe_truncate_name): New function.
 (get_section_vmas): New function.
 (add_pe_exported_sym): New function.
 (pe_get16, pe_get32, pe_as32): New functions.

>
> 1) AFAICT, the formatting of the code looks great (a rarity for a
first
> timer) except for an odd comment or two which doesn't end in a "."
as
> required for a complete sentence.  Yeah, yeah, a total nit but hey
we've
> got standards!

OK, I've fixed those comments (new diff attached). Note also that I'd
used strncmp, *and* got the "n" wrong, where I should have used strcmp
anyway.

>
> 2) I wonder if this code should be ifdef'ed somehow for Windows
since
> it will add extra code for no gain on every COFF platform.  Of
course,
> how many of those are there out there?  Maybe this isn't a huge
issue
> after all.

I wondered about that myself. However, wouldn't that suggest putting
the bulk of the code somewhere like win32-nat.c?

>
> 3) objdump -p already has the ability to read and report on the
export
> table.  I wonder if it would be useful (or possible) to generalize
this
> code so that gdb and objdump would be using the same base.  I
haven't

I assumed that since ld did it the hard way, there wasn't any proper
support for this in bfd - maybe that's not true. Obviously, sharing
this kind of code between code bases would be the ideal situation, but
I don't think I've got enough of an overview to do that.

I never new about the -p or --private-headers option to objdump! I
always thought that it should have been able to dump the export table,
but never figured out how to make it do it. That's why I went to the
ld codebase, since I knew that it would have to understand this
information.

> looked too closely but I think the code in question is in
bfd/peicode.h.
> Hmm.  Maybe objdump isn't interested in the kinds of things that gdb
> is, though, like what section a symbol is associated with...
>
> Anyway, I'll be giving this an actual test run in the next couple of
> days.  In the meantime, THANK YOU for doing this.  Even given the
very
> minor above points, I think this will be a great boon for the
Windows
> version of gdb.  This will help enormously in debugging on Windows.

Thanks for the encouragement!

>
> You will definitely need to get an assignment in to the FSF, though,
> unfortunately.  I think jimb at redhat dot com is the person to help
> you with that.

OK. will look into this further.

>
> cgf
>
> P.S.  Assuming that this works as advertised, I assume that you will
> have no objections to my releasing a new version of gdb for windows
> with this patch in it before the patch makes its way into the
official
> gdb repository, right?  I think there are a few users in the cygwin
> mailing list that would appreciate this change.

By all means - please do. You may as well use the new diff for the
comment fixes and the strncmp business.

> Special for spam email harvesters: send email to
aaaspam@sources.redhat.com
> and be permanently blocked from mailing lists at sources.redhat.com.

Alright! Sock it to 'em, redhat!

Regards,
Raoul Gough.


begin 666 coffread.c.diff2
M26YD97@Z(&-O9F9R96%D+F,-"CT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T-"E)#
M4R!F:6QE.B O8W9S+W-R8R]S<F,O9V1B+V-O9F9R96%D+F,L=@T*<F5T<FEE
M=FEN9R!R979I<VEO;B Q+C,R#0ID:69F("UC("UP("UR,2XS,B!C;V9F<F5A
M9"YC#0HJ*BH@8V]F9G)E860N8PDQ-R!$96,@,C P,B P,#HS.3HP-R M,# P
M, DQ+C,R#0HM+2T@8V]F9G)E860N8PDT($IA;B R,# S(#$V.C(S.C0Y("TP
M,# P#0HJ*BHJ*BHJ*BHJ*BHJ*BH@<W1A=&EC('9O:60@<F5A9%]O;F5?<WEM
M("AS=')U8W0@8V]F9E]S>0T**BHJ(#$W.2PQ.#0@*BHJ*@T*+2TM(#$W.2PQ
M.#8@+2TM+0T*(" )"0D@('-T<G5C="!I;G1E<FYA;%]S>6UE;G0@*BP@=6YI
M;VX@:6YT97)N86Q?875X96YT("HI.PT*(" -"B @<W1A=&EC('9O:60@8V]F
M9E]S>6UT86)?<F5A9" H;&]N9RP@=6YS:6=N960@:6YT+"!S=')U8W0@;V)J
M9FEL92 J*3L-"BL@#0HK('-T871I8R!V;VED(')E861?<&5?97AP;W)T961?
M<WEM<R H<W1R=6-T(&]B:F9I;&4@*F]B:F9I;&4I.PT*(" ,#0H@("\J(%=E
M(&%R92!C86QL960@;VYC92!P97(@<V5C=&EO;B!F<F]M(&-O9F9?<WEM9FEL
M95]R96%D+B @5V4-"B @(" @;F5E9"!T;R!E>&%M:6YE(&5A8V@@<V5C=&EO
M;B!W92!A<F4@<&%S<V5D+"!C:&5C:R!T;R!S964-"BHJ*BHJ*BHJ*BHJ*BHJ
M*B!C;V9F7W-Y;71A8E]R96%D("AL;VYG('-Y;71A8E]O9F9S970L('5N#0HJ
M*BH@,3 X-BPQ,#DQ("HJ*BH-"BTM+2 Q,#@X+#$Q,#D@+2TM+0T*(" )?0T*
M(" @(" @?0T*(" -"BL@("!I9B H*&YS>6US(#T](# I("8F("AP95]F:6QE
M*2D-"BL@(" @('L-"BL@(" @(" @+RH@5V4G=F4@9V]T(&YO(&1E8G5G9VEN
M9R!S>6UB;VQS+"!B=70@:VYO=R!H;W<@=&\@<F5A9"!T:&4@;&ES= T**R )
M(&]F(&5X<&]R=&5D('-Y;6)O;',@*&]N(&DS.#8@870@;&5A<W0I+B!4:&4@
M8V]D92!?;6EG:'1?('=O<FL-"BL@"2!O;B!O=&AE<B!A<F-H:71E8W1U<F5S
M+"!B=70@:&%S;B=T(&)E96X@=&5S=&5D+B!#:&5C:R!T:&4-"BL@"2!T87)G
M970@;F%M92!T;R!B92!O;B!T:&4@<V%F92!S:61E+B J+PT**R -"BL@(" @
M(" @8VAA<B!C;VYS=" J=&%R9V5T(#T@8F9D7V=E=%]T87)G970@*&]B:F9I
M;&4M/F]B9F0I.PT**R -"BL@(" @(" @:68@*"AS=')C;7 @*'1A<F=E="P@
M(G!E+6DS.#8B*2 ]/2 P*0T**R )("!\?" H<W1R8VUP("AT87)G970L(")P
M96DM:3,X-B(I(#T](# I*0T**R )>PT**R )("!R96%D7W!E7V5X<&]R=&5D
M7W-Y;7,@*&]B:F9I;&4I.PT**R )?0T**R @(" @?0T**R -"B @("!I9B H
M;&%S=%]S;W5R8V5?9FEL92D-"B @(" @(&-O9F9?96YD7W-Y;71A8B H;V)J
M9FEL92D[#0H@( T**BHJ*BHJ*BHJ*BHJ*BHJ(')E861?;VYE7W-Y;2 H<F5G
M:7-T97(@<W1R=6-T(&-O9F9?<WEM8F\-"BHJ*B Q,38V+#$Q-S$@*BHJ*@T*
M+2TM(#$Q.#0L,30X." M+2TM#0H@( D@(&)R96%K.PT*(" )?0T*(" @(" @
M?0T**R!]#0HK( P-"BL@+RH@061D:71I;VYA;"!S96-T:6]N(&EN9F]R;6%T
M:6]N(')E8V]R9&5D(&IU<W0@9F]R('1H92!P=7)P;W-E<R!O9@T**R @*B!R
M96%D7W!E7V5X<&]R=&5D7W-Y;7,N("HO#0HK( T**R!S=')U8W0@<F5A9%]P
M95]S96-T:6]N7V1A=&$-"BL@>PT**R @($-/4D5?041$4B!V;6%?;V9F<V5T
M.R @(" @(" @(" @(" @("\J($]F9G-E="!T;R!L;V%D960@861D<F5S<R!O
M9B!S96-T:6]N+BHO#0HK(" @=6YS:6=N960@;&]N9R!R=F%?<W1A<G0[(" @
M(" @(" @(" @+RH@4W1A<G0@;V9F<V5T('=I=&AI;B!T:&4@<&4N("HO#0HK
M(" @=6YS:6=N960@;&]N9R!R=F%?96YD.R @(" @(" @(" @(" @+RH@16YD
M(&]F9G-E="!W:71H:6X@=&AE('!E+B J+PT**R @(&5N=6T@;6EN:6UA;%]S
M>6UB;VQ?='EP92!M<U]T>7!E.R @("\J(%1Y<&4@=&\@87-S:6=N('-Y;6)O
M;',@:6X@<V5C=&EO;BX@*B\-"BL@?3L-"BL@#0HK("-D969I;F4@4$5?4T5#
M5$E/3E])3D1%6%]415A4(" @(" P#0HK("-D969I;F4@4$5?4T5#5$E/3E])
M3D1%6%]$051!(" @(" Q#0HK("-D969I;F4@4$5?4T5#5$E/3E])3D1%6%]"
M4U,@(" @(" R#0HK("-D969I;F4@4$5?4T5#5$E/3E]404),15]325I%(" @
M(" S#0HK("-D969I;F4@4$5?4T5#5$E/3E])3D1%6%])3E9!3$E$("TQ#0HK
M( T**R O*B!'970@=&AE(&EN9&5X(&]F('1H92!N86UE9"!S96-T:6]N(&EN
M(&]U<B!O=VX@87)R87DL('=H:6-H(&-O;G1A:6YS#0HK(" J('1E>'0L(&1A
M=&$@86YD(&)S<R!I;B!T:&%T(&]R9&5R+B!2971U<FX@4$5?4T5#5$E/3E])
M3D1%6%])3E9!3$E$#0HK(" J(&EF('!A<W-E9"!A;B!U;G)E8V]G;FES960@
M<V5C=&EO;B!N86UE+B J+PT**R!S=&%T:6,@:6YT(')E861?<&5?<V5C=&EO
M;E]I;F1E>" H8V]N<W0@8VAA<B J<V5C=&EO;E]N86UE*0T**R![#0HK(" @
M:68@*'-T<F-M<" H<V5C=&EO;E]N86UE+" B+G1E>'0B*2 ]/2 P*0T**R @
M(" @>PT**R @(" @("!R971U<FX@4$5?4T5#5$E/3E])3D1%6%]415A4.PT*
M*R @(" @?0T**R -"BL@("!E;'-E(&EF("AS=')C;7 @*'-E8W1I;VY?;F%M
M92P@(BYD871A(BD@/3T@,"D-"BL@(" @('L-"BL@(" @(" @<F5T=7)N(%!%
M7U-%0U1)3TY?24Y$15A?1$%403L-"BL@(" @('T-"BL@#0HK(" @96QS92!I
M9B H<W1R8VUP("AS96-T:6]N7VYA;64L("(N8G-S(BD@/3T@,"D-"BL@(" @
M('L-"BL@(" @(" @<F5T=7)N(%!%7U-%0U1)3TY?24Y$15A?0E-3.PT**R @
M(" @?0T**R -"BL@("!E;'-E#0HK(" @("![#0HK(" @(" @(')E='5R;B!0
M15]314-424].7TE.1$587TE.5D%,240[#0HK(" @("!]#0HK('T-"BL@#0HK
M("\J(%)E8V]R9"!T:&4@=FER='5A;"!M96UO<GD@861D<F5S<R!O9B!A('-E
M8W1I;VXN("HO#0HK('-T871I8R!V;VED(&=E=%]S96-T:6]N7W9M87,@*&)F
M9" J86)F9"P@87-E8W1I;VX@*G-E8W1P+"!V;VED("IC;VYT97AT*0T**R![
M#0HK(" @<W1R=6-T(')E861?<&5?<V5C=&EO;E]D871A("IS96-T:6]N<R ]
M(&-O;G1E>'0[#0HK(" @:6YT('-E8W1I>" ](')E861?<&5?<V5C=&EO;E]I
M;F1E>" H<V5C=' M/FYA;64I.PT**R -"BL@("!I9B H<V5C=&EX("$](%!%
M7U-%0U1)3TY?24Y$15A?24Y604Q)1"D-"BL@(" @('L-"BL@(" @(" @+RH@
M1&%T82!W:71H:6X@=&AE('-E8W1I;VX@<W1A<G0@870@<G9A7W-T87)T(&EN
M('1H92!P92!A;F0@870-"BL@(" @(" @("H@8F9D7V=E=%]S96-T:6]N7W9M
M82@I('=I=&AI;B!M96UO<GDN(%-T;W)E('1H92!O9F9S970N("HO#0HK( T*
M*R @(" @("!S96-T:6]N<UMS96-T:7A=+G9M85]O9F9S970-"BL@"3T@8F9D
M7V=E=%]S96-T:6]N7W9M82 H86)F9"P@<V5C=' I("T@<V5C=&EO;G-;<V5C
M=&EX72YR=F%?<W1A<G0[#0HK(" @("!]#0HK('T-"BL@# T**R O*B!#<F5A
M=&4@82!M:6YI;6%L('-Y;6)O;"!E;G1R>2!F;W(@86X@97AP;W)T960@<WEM
M8F]L+B J+PT**R!S=&%T:6,@=F]I9 T**R!A9&1?<&5?97AP;W)T961?<WEM
M("AC:&%R("IS>6U?;F%M92P-"BL@"0D@(" @('5N<VEG;F5D(&QO;F<@9G5N
M8U]R=F$L#0HK( D)(" @("!C;VYS="!S=')U8W0@<F5A9%]P95]S96-T:6]N
M7V1A=&$@*G-E8W1I;VY?9&%T82P-"BL@"0D@(" @(&-O;G-T(&-H87(@*F1L
M;%]N86UE+ T**R )"2 @(" @<W1R=6-T(&]B:F9I;&4@*F]B:F9I;&4I#0HK
M('L-"BL@(" O*B!!9&0@=&AE('-T;W)E9"!O9F9S970@=&\@9V5T('1H92!L
M;V%D960@861D<F5S<R!O9B!T:&4@<WEM8F]L+B J+PT**R @($-/4D5?041$
M4B!V;6$@/2!F=6YC7W)V82 K('-E8W1I;VY?9&%T82T^=FUA7V]F9G-E=#L-
M"BL@("!C:&%R("IQ=6%L:69I961?;F%M92 ](# [#0HK(" @:6YT(&1L;%]N
M86UE7VQE;B ]('-T<FQE;B H9&QL7VYA;64I.PT**R @(&EN="!C;W5N=#L-
M"BL@#0HK(" @+RH@1V5N97)A=&4@82 H:&]P969U;&QY('5N:7%U92D@<75A
M;&EF:65D(&YA;64@=7-I;F<@=&AE(&9I<G-T('!A<G0-"BL@(" @*B!O9B!T
M:&4@9&QL(&YA;64L(&4N9RX@2T523D5,,S(A061D071O;4$N(%1H:7,@;6%T
M8VAE<R!T:&4@<W1Y;&4-"BL@(" @*B!U<V5D(&)Y('=I;F1B9R!F<F]M('1H
M92 B36EC<F]S;V9T($1E8G5G9VEN9R!4;V]L<R!F;W(@5VEN9&]W<R(N("HO
M#0HK( T**R @('%U86QI9FEE9%]N86UE(#T@>&UA;&QO8R H9&QL7VYA;65?
M;&5N("L@<W1R;&5N("AS>6U?;F%M92D@*R R*3L-"BL@#0HK(" @<W1R;F-P
M>2 H<75A;&EF:65D7VYA;64L(&1L;%]N86UE+"!D;&Q?;F%M95]L96XI.PT*
M*R @('%U86QI9FEE9%]N86UE6V1L;%]N86UE7VQE;ET@/2 G(2<[#0HK(" @
M<W1R8W!Y("AQ=6%L:69I961?;F%M92 K(&1L;%]N86UE7VQE;B K(#$L('-Y
M;5]N86UE*3L-"BL@#0HK(" @<F5C;W)D7VUI;FEM86Q?<WEM8F]L("AQ=6%L
M:69I961?;F%M92P-"BL@"0D)('9M82P-"BL@"0D)('-E8W1I;VY?9&%T82T^
M;7-?='EP92P-"BL@"0D)(&]B:F9I;&4I.PT**R -"BL@("!X9G)E92 H<75A
M;&EF:65D7VYA;64I.PT**R -"BL@(" O*B!%;G1E<B!T:&4@<&QA:6X@;F%M
M92!A<R!W96QL+"!W:&EC:"!M:6=H="!N;W0@8F4@=6YI<75E+B J+PT**R @
M(')E8V]R9%]M:6YI;6%L7W-Y;6)O;" H<WEM7VYA;64L#0HK( D)"2!V;6$L
M#0HK( D)"2!S96-T:6]N7V1A=&$M/FUS7W1Y<&4L#0HK( D)"2!O8FIF:6QE
M*3L-"BL@?0T**R -"BL@+RH@5')U;F-A=&4@82!D;&Q?;F%M92!A="!T:&4@
M9FER<W0@9&]T(&-H87)A8W1E<BX@*B\-"BL@<W1A=&EC('9O:60@<F5A9%]P
M95]T<G5N8V%T95]N86UE("AC:&%R("ID;&Q?;F%M92D-"BL@>PT**R @('=H
M:6QE("@J9&QL7VYA;64I#0HK(" @("![#0HK(" @(" @(&EF("@H*F1L;%]N
M86UE*2 ]/2 G+B<I#0HK( E[#0HK( D@("ID;&Q?;F%M92 ]("=<,"<[("\J
M('1R=6YC871E<R!A;F0@8V%U<V5S(&QO;W @97AI="X@*B\-"BL@"7T-"BL@
M#0HK(" @(" @(&5L<V4-"BL@"7L-"BL@"2 @*RMD;&Q?;F%M93L-"BL@"7T-
M"BL@(" @('T-"BL@?0T**R ,#0HK("\J($QA<W0M<F5S;W)T('-U<'!O<G0@
M9F]R("AN;VXM9&5B=6<I('-Y;6)O;',@97AP;W)T960@9G)O;2!P;W)T86)L
M90T**R @*B!E>&5C=71A8FQE<RP@=7-E9"!W:&5N('1H97)E(&%R92!N;R!O
M=&AE<B!R96-O9VYI>F5D('-Y;6)O;',N($-O9&4-"BL@("H@;&EF=&5D("AW
M:71H(&UO9&EF:6-A=&EO;G,I(&9R;VT@<&4M9&QL+F,@9G)O;2!L9"X@*B\-
M"BL@#0HK('-T871I8R!U;G-I9VYE9"!I;G0-"BL@<&5?9V5T,38@*&%B9F0L
M('=H97)E*0T**R @(" @(&)F9" J86)F9#L-"BL@(" @("!I;G0@=VAE<F4[
M#0HK('L-"BL@("!U;G-I9VYE9"!C:&%R(&);,ET[#0HK( T**R @(&)F9%]S
M965K("AA8F9D+" H9FEL95]P='(I('=H97)E+"!3145+7U-%5"D[#0HK(" @
M8F9D7V)R96%D("AB+" H8F9D7W-I>F5?='EP92D@,BP@86)F9"D[#0HK(" @
M<F5T=7)N(&);,%T@*R H8ELQ72 \/" X*3L-"BL@?0T**R -"BL@<W1A=&EC
M('5N<VEG;F5D(&EN= T**R!P95]G970S,B H86)F9"P@=VAE<F4I#0HK(" @
M(" @8F9D("IA8F9D.PT**R @(" @(&EN="!W:&5R93L-"BL@>PT**R @('5N
M<VEG;F5D(&-H87(@8ELT73L-"BL@#0HK(" @8F9D7W-E96L@*&%B9F0L("AF
M:6QE7W!T<BD@=VAE<F4L(%-%14M?4T54*3L-"BL@("!B9F1?8G)E860@*&(L
M("AB9F1?<VEZ95]T>7!E*2 T+"!A8F9D*3L-"BL@("!R971U<FX@8ELP72 K
M("AB6S%=(#P\(#@I("L@*&);,ET@/#P@,38I("L@*&);,UT@/#P@,C0I.PT*
M*R!]#0HK( T**R!S=&%T:6,@=6YS:6=N960@:6YT#0HK('!E7V%S,S(@*'!T
M<BD-"BL@(" @("!V;VED("IP='([#0HK('L-"BL@("!U;G-I9VYE9"!C:&%R
M("IB(#T@<'1R.PT**R -"BL@("!R971U<FX@8ELP72 K("AB6S%=(#P\(#@I
M("L@*&);,ET@/#P@,38I("L@*&);,UT@/#P@,C0I.PT**R!]#0HK( T**R O
M*B!296%D('1H92 H;F]N+61E8G5G*2!E>'!O<G0@<WEM8F]L('1A8FQE(&9R
M;VT@82!P;W)T86)L90T**R @*B!E>&5C=71A8FQE+B @;W)I9VEN86QL>2!F
M<F]M('1H92!L9"!F=6YC=&EO;B!P95]I;7!L:65D7VEM<&]R=%]D;&P-"BL@
M("H@9G)O;2!P92UD;&PN8RX@*B\-"BL@#0HK('-T871I8R!V;VED(')E861?
M<&5?97AP;W)T961?<WEM<R H<W1R=6-T(&]B:F9I;&4@*F]B:F9I;&4I#0HK
M('L-"BL@("!B9F0@*F1L;" ](&]B:F9I;&4M/F]B9F0[#0HK(" @=6YS:6=N
M960@;&]N9R!P95]H96%D97)?;V9F<V5T+"!O<'1H9')?;V9S+"!N=6U?96YT
M<FEE<RP@:3L-"BL@("!U;G-I9VYE9"!L;VYG(&5X<&]R=%]R=F$L(&5X<&]R
M=%]S:7IE+"!N<V5C=&EO;G,L('-E8W!T<BP@97AP<'1R.PT**R @('5N<VEG
M;F5D(&QO;F<@97AP7V9U;F-B87-E.PT**R @('5N<VEG;F5D(&-H87(@*F5X
M<&1A=&$L("IE<G9A.PT**R @('5N<VEG;F5D(&QO;F<@;F%M95]R=F%S+"!O
M<F1I;F%L<RP@;F5X<"P@;W)D8F%S93L-"BL@("!C:&%R("ID;&Q?;F%M93L-
M"BL@#0HK(" @+RH@07)R87D@96QE;65N=',@87)E(&9O<B!T97AT+"!D871A
M(&%N9"!B<W,@:6X@=&AA="!O<F1E<@T**R @(" @($EN:71I86QI>F%T:6]N
M('=I=&@@<W1A<G1?<G9A(#X@96YD7W)V82!G=6%R86YT965S('1H870-"BL@
M(" @("!U;G5S960@<V5C=&EO;G,@=V]N)W0@8F4@;6%T8VAE9"X@*B\-"BL@
M("!S=')U8W0@<F5A9%]P95]S96-T:6]N7V1A=&$@<V5C=&EO;E]D871A6U!%
M7U-%0U1)3TY?5$%"3$5?4TE:15T-"BL@(" @(#T@>R![,"P@,2P@,"P@;7-T
M7W1E>'1]+ T**R )>S L(#$L(# L(&US=%]D871A?2P-"BL@"7LP+" Q+" P
M+"!M<W1?8G-S?2!].PT**R -"BL@("!S=')U8W0@8VQE86YU<" J8F%C:U]T
M;R ](# [#0HK( T**R @("\J($=E="!P95]H96%D97(L(&]P=&EO;F%L(&AE
M861E<B!A;F0@;G5M8F5R<R!O9B!E>'!O<G0@96YT<FEE<RX@("HO#0HK(" @
M<&5?:&5A9&5R7V]F9G-E=" ]('!E7V=E=#,R("AD;&PL(#!X,V,I.PT**R @
M(&]P=&AD<E]O9G,@/2!P95]H96%D97)?;V9F<V5T("L@-" K(#(P.PT**R @
M(&YU;5]E;G1R:65S(#T@<&5?9V5T,S(@*&1L;"P@;W!T:&1R7V]F<R K(#DR
M*3L-"BL@#0HK(" @:68@*&YU;5]E;G1R:65S(#P@,2D@+RH@3F\@97AP;W)T
M<RX@("HO#0HK(" @("![#0HK(" @(" @(')E='5R;CL-"BL@(" @('T-"BL@
M#0HK(" @97AP;W)T7W)V82 ]('!E7V=E=#,R("AD;&PL(&]P=&AD<E]O9G,@
M*R Y-BD[#0HK(" @97AP;W)T7W-I>F4@/2!P95]G970S,B H9&QL+"!O<'1H
M9')?;V9S("L@,3 P*3L-"BL@("!N<V5C=&EO;G,@/2!P95]G970Q-B H9&QL
M+"!P95]H96%D97)?;V9F<V5T("L@-" K(#(I.PT**R @('-E8W!T<B ]("AP
M95]H96%D97)?;V9F<V5T("L@-" K(#(P("L-"BL@"2 @("!P95]G970Q-B H
M9&QL+"!P95]H96%D97)?;V9F<V5T("L@-" K(#$V*2D[#0HK(" @97AP<'1R
M(#T@,#L-"BL@#0HK(" @+RH@1V5T('1H92!R=F$@86YD('-I>F4@;V8@=&AE
M(&5X<&]R="!S96-T:6]N+B @*B\@#0HK(" @9F]R("AI(#T@,#L@:2 \(&YS
M96-T:6]N<SL@:2LK*0T**R @(" @>PT**R @(" @("!C:&%R('-N86UE6SA=
M.PT**R @(" @("!U;G-I9VYE9"!L;VYG('-E8W!T<C$@/2!S96-P='(@*R T
M," J(&D[#0HK(" @(" @('5N<VEG;F5D(&QO;F<@=F%D9'(@/2!P95]G970S
M,B H9&QL+"!S96-P='(Q("L@,3(I.PT**R @(" @("!U;G-I9VYE9"!L;VYG
M('9S:7IE(#T@<&5?9V5T,S(@*&1L;"P@<V5C<'1R,2 K(#$V*3L-"BL@(" @
M(" @=6YS:6=N960@;&]N9R!F<'1R(#T@<&5?9V5T,S(@*&1L;"P@<V5C<'1R
M,2 K(#(P*3L-"BL@#0HK(" @(" @(&)F9%]S965K("AD;&PL("AF:6QE7W!T
M<BD@<V5C<'1R,2P@4T5%2U]3150I.PT**R @(" @("!B9F1?8G)E860@*'-N
M86UE+" H8F9D7W-I>F5?='EP92D@."P@9&QL*3L-"BL@#0HK(" @(" @(&EF
M("AV861D<B \/2!E>'!O<G1?<G9A("8F('9A9&1R("L@=G-I>F4@/B!E>'!O
M<G1?<G9A*0T**R )>PT**R )("!E>'!P='(@/2!F<'1R("L@*&5X<&]R=%]R
M=F$@+2!V861D<BD[#0HK( D@(&EF("AE>'!O<G1?<G9A("L@97AP;W)T7W-I
M>F4@/B!V861D<B K('9S:7IE*0T**R )(" @(&5X<&]R=%]S:7IE(#T@=G-I
M>F4@+2 H97AP;W)T7W)V82 M('9A9&1R*3L-"BL@"2 @8G)E86L[#0HK( E]
M#0HK(" @("!]#0HK( T**R @(&EF("AE>'!O<G1?<VEZ92 ]/2 P*0T**R @
M(" @>PT**R @(" @(" O*B!%;7!T>2!E>'!O<G0@=&%B;&4N("HO#0HK(" @
M(" @(')E='5R;CL-"BL@(" @('T-"BL@#0HK(" @+RH@4V-A;B!S96-T:6]N
M<R!A;F0@<W1O<F4@=&AE(&)A<V4@86YD('-I>F4@;V8@=&AE(')E;&5V86YT
M('-E8W1I;VYS+B J+PT**R @(&9O<B H:2 ](# [(&D@/"!N<V5C=&EO;G,[
M(&DK*RD-"BL@(" @('L-"BL@(" @(" @=6YS:6=N960@;&]N9R!S96-P='(Q
M(#T@<V5C<'1R("L@-# @*B!I.PT**R @(" @("!U;G-I9VYE9"!L;VYG('9S
M:7IE(#T@<&5?9V5T,S(@*&1L;"P@<V5C<'1R,2 K(#@I.PT**R @(" @("!U
M;G-I9VYE9"!L;VYG('9A9&1R(#T@<&5?9V5T,S(@*&1L;"P@<V5C<'1R,2 K
M(#$R*3L-"BL@(" @(" @=6YS:6=N960@;&]N9R!F;&%G<R ]('!E7V=E=#,R
M("AD;&PL('-E8W!T<C$@*R S-BD[#0HK(" @(" @(&-H87(@<V5C7VYA;65;
M.5T[#0HK(" @(" @(&EN="!S96-T:7@[#0HK( T**R @(" @("!S96-?;F%M
M95LX72 ]("=<,"<[#0HK(" @(" @(&)F9%]S965K("AD;&PL("AF:6QE7W!T
M<BD@<V5C<'1R,2 K(# L(%-%14M?4T54*3L-"BL@(" @(" @8F9D7V)R96%D
M("AS96-?;F%M92P@*&)F9%]S:7IE7W1Y<&4I(#@L(&1L;"D[#0HK( T**R @
M(" @("!S96-T:7@@/2!R96%D7W!E7W-E8W1I;VY?:6YD97@@*'-E8U]N86UE
M*3L-"BL@#0HK(" @(" @(&EF("AS96-T:7@@(3T@4$5?4T5#5$E/3E])3D1%
M6%])3E9!3$E$*0T**R )>PT**R )("!S96-T:6]N7V1A=&%;<V5C=&EX72YR
M=F%?<W1A<G0@/2!V861D<CL-"BL@"2 @<V5C=&EO;E]D871A6W-E8W1I>%TN
M<G9A7V5N9" ]('9A9&1R("L@=G-I>F4[#0HK( E]#0HK(" @("!]#0HK( T*
M*R @(&5X<&1A=&$@/2 H=6YS:6=N960@8VAA<B J*2!X;6%L;&]C("AE>'!O
M<G1?<VEZ92D[#0HK(" @8F%C:U]T;R ](&UA:V5?8VQE86YU<" H>&9R964L
M(&5X<&1A=&$I.PT**R -"BL@("!B9F1?<V5E:R H9&QL+" H9FEL95]P='(I
M(&5X<'!T<BP@4T5%2U]3150I.PT**R @(&)F9%]B<F5A9" H97AP9&%T82P@
M*&)F9%]S:7IE7W1Y<&4I(&5X<&]R=%]S:7IE+"!D;&PI.PT**R @(&5R=F$@
M/2!E>'!D871A("T@97AP;W)T7W)V83L-"BL@#0HK(" @;F5X<" ]('!E7V%S
M,S(@*&5X<&1A=&$@*R R-"D[#0HK(" @;F%M95]R=F%S(#T@<&5?87,S,B H
M97AP9&%T82 K(#,R*3L-"BL@("!O<F1I;F%L<R ]('!E7V%S,S(@*&5X<&1A
M=&$@*R S-BD[#0HK(" @;W)D8F%S92 ]('!E7V%S,S(@*&5X<&1A=&$@*R Q
M-BD[#0HK(" @97AP7V9U;F-B87-E(#T@<&5?87,S,B H97AP9&%T82 K(#(X
M*3L-"BL@#0HK(" @+RH@57-E(&EN=&5R;F%L(&1L;"!N86UE(&EN<W1E860@
M;V8@9G5L;"!P871H;F%M92X@*B\-"BL@("!D;&Q?;F%M92 ]('!E7V%S,S(@
M*&5X<&1A=&$@*R Q,BD@*R!E<G9A.PT**R -"BL@("!B9F1?;6%P7V]V97)?
M<V5C=&EO;G,@*&1L;"P@9V5T7W-E8W1I;VY?=FUA<RP@<V5C=&EO;E]D871A
M*3L-"BL@#0HK(" @<')I;G1F7V9I;'1E<F5D("@B36EN:6UA;"!S>6UB;VQS
M(&9R;VT@)7,N+BXB+"!D;&Q?;F%M92D[#0HK(" @=W)A<%]H97)E("@B(BD[
M#0HK( T**R @("\J(%1R=6YC871E(&YA;64@870@9FER<W0@9&]T('1O(&%V
M;VED('!R;V)L96US('=I=&@@=&AE('%U86QI9FEE9 T**R @(" @(&YA;65S
M('=E(&=E;F5R871E+B!3:&]U;&0@;6%Y8F4@86QS;R!C;VYV97)T('1O(&%L
M;"!L;W=E<B!C87-E#0HK(" @(" @9F]R(&-O;G9E;FEE;F-E(&]N(%=I;F1O
M=W,N("HO#0HK(" @<F5A9%]P95]T<G5N8V%T95]N86UE("AD;&Q?;F%M92D[
M#0HK( T**R @("\J($ET97)A=&4@=&AR;W5G:"!T:&4@;&ES="!O9B!S>6UB
M;VQS+B @*B\-"BL@("!F;W(@*&D@/2 P.R!I(#P@;F5X<#L@:2LK*0T**R @
M(" @>PT**R @(" @(" O*B!0;VEN=&5R('1O('1H92!N86UE<R!V96-T;W(N
M(" J+PT**R @(" @("!U;G-I9VYE9"!L;VYG(&YA;65?<G9A(#T@<&5?87,S
M,B H97)V82 K(&YA;65?<G9A<R K(&D@*B T*3L-"BL@#0HK(" @(" @("\J
M(%!O:6YT97(@=&\@=&AE(&9U;F-T:6]N(&%D9')E<W,@=F5C=&]R+B @*B\@
M#0HK(" @(" @('5N<VEG;F5D(&QO;F<@9G5N8U]R=F$@/2!P95]A<S,R("AE
M<G9A("L@97AP7V9U;F-B87-E("L@:2 J(#0I.PT**R -"BL@(" @(" @+RH@
M1FEN9"!T:&ES('-Y;6)O;"=S('-E8W1I;VX@:6X@;W5R(&]W;B!A<G)A>2X@
M*B\-"BL@(" @(" @:6YT('-E8W1I>" ](# [#0HK( T**R @(" @("!F;W(@
M*'-E8W1I>" ](# [('-E8W1I>" \(%!%7U-%0U1)3TY?5$%"3$5?4TE:13L@
M*RMS96-T:7@I#0HK( E[#0HK( D@(&EF("@H9G5N8U]R=F$@/CT@<V5C=&EO
M;E]D871A6W-E8W1I>%TN<G9A7W-T87)T*0T**R )(" @(" @)B8@*&9U;F-?
M<G9A(#P@<V5C=&EO;E]D871A6W-E8W1I>%TN<G9A7V5N9"DI#0HK( D@(" @
M>PT**R )(" @(" @861D7W!E7V5X<&]R=&5D7W-Y;2 H97)V82 K(&YA;65?
M<G9A+ T**R )"0D)(" @9G5N8U]R=F$L#0HK( D)"0D@("!S96-T:6]N7V1A
M=&$@*R!S96-T:7@L#0HK( D)"0D@("!D;&Q?;F%M92P-"BL@"0D)"2 @(&]B
M:F9I;&4I.PT**R )(" @(" @8G)E86L[#0HK( D@(" @?0T**R )?0T**R @
M(" @?0T**R -"BL@(" O*B!D:7-C87)D(&5X<&1A=&$N("HO#0HK(" @9&]?
M8VQE86YU<',@*&)A8VM?=&\I.PT*("!]#0H@( P-"B @+RH@4W5P<&]R="!F
=;W(@<W1R:6YG('1A8FQE(&AA;F1L:6YG("HO#0H`
`
end

Re: coffread.c extension for DLLs without debugging symbols

[Eli Zaretskii]

> From: "Raoul Gough" <RaoulGough@yahoo.co.uk>
> Date: Sat, 4 Jan 2003 16:25:16 -0000
> 
> How's this:
> 
> 2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>
> 
>  * coffread.c: Support non-debug export symbols for win32 DLLs.
>  (coff_symtab_read): call read_pe_exported_syms iff no symbols
>  found and objfile is "pe-i386" or "pei-i386".
>  (read_pe_exported_syms): New function.
>  (read_pe_section_data): New struct (temporary section info).
>  (read_pe_section_index): New function.
>  (read_pe_truncate_name): New function.
>  (get_section_vmas): New function.
>  (add_pe_exported_sym): New function.
>  (pe_get16, pe_get32, pe_as32): New functions.

This is okay, thanks.

> > 2) I wonder if this code should be ifdef'ed somehow for Windows
> since
> > it will add extra code for no gain on every COFF platform.  Of
> course,
> > how many of those are there out there?  Maybe this isn't a huge
> issue
> > after all.
> 
> I wondered about that myself. However, wouldn't that suggest putting
> the bulk of the code somewhere like win32-nat.c?

The DJGPP port of GDB uses COFF (and doesn't support DLLs).

Re: coffread.c extension for DLLs without debugging symbols

[Christopher Faylor]

On Sat, Jan 04, 2003 at 04:25:16PM -0000, Raoul Gough wrote:
>"Christopher Faylor" <cgf@redhat.com> wrote in message
>news:20030104044408.GA7364@redhat.com...
>>On Fri, Jan 03, 2003 at 07:39:31PM -0000, Raoul Gough wrote: 0) The
>>ChangeLog needs more information.  Every new function should be
>>mentioned and changes to specific functions should be documented.
>
>How's this:
>
>2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>
>
> * coffread.c: Support non-debug export symbols for win32 DLLs.
> (coff_symtab_read): call read_pe_exported_syms iff no symbols
> found and objfile is "pe-i386" or "pei-i386".
> (read_pe_exported_syms): New function.
> (read_pe_section_data): New struct (temporary section info).
> (read_pe_section_index): New function.
> (read_pe_truncate_name): New function.
> (get_section_vmas): New function.
> (add_pe_exported_sym): New function.
> (pe_get16, pe_get32, pe_as32): New functions.

Looks great.

>> 1) AFAICT, the formatting of the code looks great (a rarity for a first
>> timer) except for an odd comment or two which doesn't end in a "." as
>> required for a complete sentence.  Yeah, yeah, a total nit but hey we've
>> got standards!
>
>OK, I've fixed those comments (new diff attached). Note also that I'd
>used strncmp, *and* got the "n" wrong, where I should have used strcmp
>anyway.

Huh.  Well, I tried your patch and it worked fine regardless.  It's funny
to see actual symbols being reported now rather than random hex addresses
or, worse, some random unrelated symbol plus a large offset.
>
>>2) I wonder if this code should be ifdef'ed somehow for Windows since
>>it will add extra code for no gain on every COFF platform.  Of course,
>>how many of those are there out there?  Maybe this isn't a huge issue
>>after all.
>
>I wondered about that myself.  However, wouldn't that suggest putting
>the bulk of the code somewhere like win32-nat.c?

That would be fine with me (especially since I can approve that part of
gdb).  So, you'd need some kind of hooks in coffread.c to handle this.
I guess we should wait for the coffread maintainer to offer an opinion
before you go to this effort, though.

>>3) objdump -p already has the ability to read and report on the export
>>table.  I wonder if it would be useful (or possible) to generalize this
>>code so that gdb and objdump would be using the same base.  I haven't
>
>I assumed that since ld did it the hard way, there wasn't any proper
>support for this in bfd - maybe that's not true. Obviously, sharing
>this kind of code between code bases would be the ideal situation, but
>I don't think I've got enough of an overview to do that.

Hmm.  You're right ld does it the hard way doesn't it?  Well, I don't
want to saddle you with one of those "The best way to deal with this
is to redesign binutils, gcc, and awk so that it will all be transparent
to gdb" type of deals.  If you can find some kind of common ground in
bfd that ld, gdb, and objdump (and who knows, objcopy?) can all use then
that would be a huge win.  Otherwise your current plan is fine, IMO.

>> P.S.  Assuming that this works as advertised, I assume that you will
>> have no objections to my releasing a new version of gdb for windows
>> with this patch in it before the patch makes its way into the official
>> gdb repository, right?  I think there are a few users in the cygwin
>> mailing list that would appreciate this change.
>
>By all means - please do. You may as well use the new diff for the
>comment fixes and the strncmp business.

Ok.  Coming soon to a cygwin mirror near you.

>>Special for spam email harvesters: send email to
>>aaaspam@sources.redhat.com and be permanently blocked from mailing
>>lists at sources.redhat.com.
>
>Alright! Sock it to 'em, redhat!

Heh.  So far the aaaspam@sources.redhat.com mailing list is in the top
fifteen most popular mailing lists at sources.redhat.com.  Imagine that.

If anyone is so inclined as to mention aaaspam@sources.redhat.com,
aaaspam@cygwin.com, aaaspam@sourceware.org, or aaaspam@gcc.gnu.org in
their messages to the internet, it would probably help in the war on
spam.

cgf

Re: coffread.c extension for DLLs without debugging symbols

[Mark Kettenis]

Christopher Faylor <cgf@redhat.com> writes:

>>>2) I wonder if this code should be ifdef'ed somehow for Windows since
>>>it will add extra code for no gain on every COFF platform.  Of course,
>>>how many of those are there out there?  Maybe this isn't a huge issue
>>>after all.
>>
>>I wondered about that myself.  However, wouldn't that suggest putting
>>the bulk of the code somewhere like win32-nat.c?
>
> That would be fine with me (especially since I can approve that part of
> gdb).  So, you'd need some kind of hooks in coffread.c to handle this.
> I guess we should wait for the coffread maintainer to offer an opinion
> before you go to this effort, though.

Well, I assume this code would be usefull when cross-debugging too.
If so, a *-nat.c file would be the wrong place to add it.  You could
create a win32-tdep.c file though.

Mark

Re: coffread.c extension for DLLs without debugging symbols

[Christopher Faylor]

On Sun, Jan 05, 2003 at 03:44:44PM +0100, Mark Kettenis wrote:
>Christopher Faylor <cgf@redhat.com> writes:
>
>>>>2) I wonder if this code should be ifdef'ed somehow for Windows since
>>>>it will add extra code for no gain on every COFF platform.  Of course,
>>>>how many of those are there out there?  Maybe this isn't a huge issue
>>>>after all.
>>>
>>>I wondered about that myself.  However, wouldn't that suggest putting
>>>the bulk of the code somewhere like win32-nat.c?
>>
>> That would be fine with me (especially since I can approve that part of
>> gdb).  So, you'd need some kind of hooks in coffread.c to handle this.
>> I guess we should wait for the coffread maintainer to offer an opinion
>> before you go to this effort, though.
>
>Well, I assume this code would be usefull when cross-debugging too.
>If so, a *-nat.c file would be the wrong place to add it.  You could
>create a win32-tdep.c file though.

Cross debugging to a windows box?  Does anyone actually do that?  I know
it is theoretically possible with, *cough* rda *cough* but I wasn't aware
of anyone actually doing this.

Regardless, win32-tdep.c would be a more logically correct place to put
it.

cgf

Re: coffread.c extension for DLLs without debugging symbols

[Daniel Jacobowitz]

On Sun, Jan 05, 2003 at 12:18:26PM -0500, Christopher Faylor wrote:
> On Sun, Jan 05, 2003 at 03:44:44PM +0100, Mark Kettenis wrote:
> >Christopher Faylor <cgf@redhat.com> writes:
> >
> >>>>2) I wonder if this code should be ifdef'ed somehow for Windows since
> >>>>it will add extra code for no gain on every COFF platform.  Of course,
> >>>>how many of those are there out there?  Maybe this isn't a huge issue
> >>>>after all.
> >>>
> >>>I wondered about that myself.  However, wouldn't that suggest putting
> >>>the bulk of the code somewhere like win32-nat.c?
> >>
> >> That would be fine with me (especially since I can approve that part of
> >> gdb).  So, you'd need some kind of hooks in coffread.c to handle this.
> >> I guess we should wait for the coffread maintainer to offer an opinion
> >> before you go to this effort, though.
> >
> >Well, I assume this code would be usefull when cross-debugging too.
> >If so, a *-nat.c file would be the wrong place to add it.  You could
> >create a win32-tdep.c file though.
> 
> Cross debugging to a windows box?  Does anyone actually do that?  I know
> it is theoretically possible with, *cough* rda *cough* but I wasn't aware
> of anyone actually doing this.
> 
> Regardless, win32-tdep.c would be a more logically correct place to put
> it.

In any case, it's nicer to have it in the tdep file; it's a step
towards letting people who make large mechanical changes verify that it
still compiles.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: coffread.c extension for DLLs without debugging symbols

[Elena Zannoni]

Eli Zaretskii writes:
 > > From: "Raoul Gough" <RaoulGough@yahoo.co.uk>
 > > Date: Fri, 3 Jan 2003 19:39:31 -0000
 > > 
 > > This is my *first* gdb patch submission,
 > > so someone with more experience should probably take a good look at
 > > (e.g. is coffread.c the right place for this kind of code?).
 > 
 > Lesson number 1: post the diffs as plain text, not uuencoded or
 > otherwise encoded.  Some people, such as myself, don't have time to
 > open binary attachments, but do have time to read a patch that's in
 > plain text.
 > 
 > Also, please include "[RFA]" in the subject, so that we know you are
 > seeking an approval for your patch.
 > 
 > > Proposed ChangeLog entry, assuming the code is accepted:
 > > 
 > > 2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>
 > > 
 > >  * coffread.c: Support non-debug export symbols for win32 DLLs
 > 
 > This should mention every function where changes are made, preferably
 > with a description of a change in each one of them.
 > 
 > And thanks for working on this.


I am including the plain text of the last version of the patch.
I have noticed a few functions are using K&R style, please use ISO C.
Also the formatting for functions should be

int
foo (int par1, int par2)

so that grep ^foo will work.

(sorry, I have to ask) Do you have a copyright assignment with the FSF?

As far as the new code being triggered, could you do it based on the
existance of some particular section/data in the objfile?  I see that
you bail out of read_pe_exported_syms if there are no exports, could
something on the same flavour be done? (like using bfd_get_flavour, 
or bfd_get_section_by_name, etc)

About location of the code, add maybe a coff-pe-read.c? (ulgh) But
since it deals with reading symbols, I would think it more logical to
stay in some object/debug format related file rather than in a target
related file.

Elena


Index: coffread.c
===================================================================
RCS file: /cvs/src/src/gdb/coffread.c,v
retrieving revision 1.32
diff -c -p -r1.32 coffread.c
*** coffread.c	17 Dec 2002 00:39:07 -0000	1.32
--- coffread.c	3 Jan 2003 18:24:39 -0000
*************** static void read_one_sym (struct coff_sy
*** 179,184 ****
--- 179,186 ----
  			  struct internal_syment *, union internal_auxent *);
  
  static void coff_symtab_read (long, unsigned int, struct objfile *);
+ 
+ static void read_pe_exported_syms (struct objfile *objfile);
  \f
  /* We are called once per section from coff_symfile_read.  We
     need to examine each section we are passed, check to see
*************** coff_symtab_read (long symtab_offset, un
*** 1086,1091 ****
--- 1088,1109 ----
  	}
      }
  
+   if ((nsyms == 0) && (pe_file))
+     {
+       /* We've got no debugging symbols, but know how to read the list
+ 	 of exported symbols (on i386 at least). The code _might_ work
+ 	 on other architectures, but hasn't been tested. Check the
+ 	 target name to be on the safe side */
+ 
+       char const *target = bfd_get_target (objfile->obfd);
+ 
+       if ((strncmp (target, "pe-i386", 3) == 0)
+ 	  || (strncmp (target, "pei-i386", 4) == 0))
+ 	{
+ 	  read_pe_exported_syms (objfile);
+ 	}
+     }
+ 
    if (last_source_file)
      coff_end_symtab (objfile);
  
*************** read_one_sym (register struct coff_symbo
*** 1166,1171 ****
--- 1184,1488 ----
  	  break;
  	}
      }
+ }
+ \f
+ /* Additional section information recorded just for the purposes of
+  * read_pe_exported_syms */
+ 
+ struct read_pe_section_data
+ {
+   CORE_ADDR vma_offset;               /* Offset to loaded address of section */
+   unsigned long rva_start;            /* Start offset within the pe */
+   unsigned long rva_end;              /* End offset within the pe */
+   enum minimal_symbol_type ms_type;   /* Type to assign symbols in section */
+ };
+ 
+ #define PE_SECTION_INDEX_TEXT     0
+ #define PE_SECTION_INDEX_DATA     1
+ #define PE_SECTION_INDEX_BSS      2
+ #define PE_SECTION_TABLE_SIZE     3
+ #define PE_SECTION_INDEX_INVALID -1
+ 
+ /* Get the index of the named section in our own array, which contains
+  * text, data and bss in that order. Return PE_SECTION_INDEX_INVALID
+  * if passed an unrecognised section name */
+ static int read_pe_section_index (const char *section_name)
+ {
+   if (strcmp (section_name, ".text") == 0)
+     {
+       return PE_SECTION_INDEX_TEXT;
+     }
+ 
+   else if (strcmp (section_name, ".data") == 0)
+     {
+       return PE_SECTION_INDEX_DATA;
+     }
+ 
+   else if (strcmp (section_name, ".bss") == 0)
+     {
+       return PE_SECTION_INDEX_BSS;
+     }
+ 
+   else
+     {
+       return PE_SECTION_INDEX_INVALID;
+     }
+ }
+ 
+ /* Record the virtual memory address of a section */
+ static void get_section_vmas (bfd *abfd, asection *sectp, void *context)
+ {
+   struct read_pe_section_data *sections = context;
+   int sectix = read_pe_section_index (sectp->name);
+ 
+   if (sectix != PE_SECTION_INDEX_INVALID)
+     {
+       /* Data within the section start at rva_start in the pe and at
+        * bfd_get_section_vma() within memory. Store the offset */
+ 
+       sections[sectix].vma_offset
+ 	= bfd_get_section_vma (abfd, sectp) - sections[sectix].rva_start;
+     }
+ }
+ \f
+ /* Create a minimal symbol entry for an exported symbol */
+ static void
+ add_pe_exported_sym (char *sym_name,
+ 		     unsigned long func_rva,
+ 		     const struct read_pe_section_data *section_data,
+ 		     const char *dll_name,
+ 		     struct objfile *objfile)
+ {
+   /* Add the stored offset to get the loaded address of the symbol */
+   CORE_ADDR vma = func_rva + section_data->vma_offset;
+   char *qualified_name = 0;
+   int dll_name_len = strlen (dll_name);
+   int count;
+ 
+   /* Generate a (hopefully unique) qualified name using the first part
+    * of the dll name, e.g. KERNEL32!AddAtomA. This matches the style
+    * used by windbg from the "Microsoft Debugging Tools for Windows" */
+ 
+   qualified_name = xmalloc (dll_name_len + strlen (sym_name) + 2);
+ 
+   strncpy (qualified_name, dll_name, dll_name_len);
+   qualified_name[dll_name_len] = '!';
+   strcpy (qualified_name + dll_name_len + 1, sym_name);
+ 
+   record_minimal_symbol (qualified_name,
+ 			 vma,
+ 			 section_data->ms_type,
+ 			 objfile);
+ 
+   xfree (qualified_name);
+ 
+   /* Enter the plain name as well, which might not be unique */
+   record_minimal_symbol (sym_name,
+ 			 vma,
+ 			 section_data->ms_type,
+ 			 objfile);
+ }
+ 
+ /* Truncate a dll_name at the first dot character */
+ static void read_pe_truncate_name (char *dll_name)
+ {
+   while (*dll_name)
+     {
+       if ((*dll_name) == '.')
+ 	{
+ 	  *dll_name = '\0'; /* truncates and causes loop exit */
+ 	}
+ 
+       else
+ 	{
+ 	  ++dll_name;
+ 	}
+     }
+ }
+ \f
+ /* Last-resort support for (non-debug) symbols exported from portable
+  * executables, used when there are no other recognized symbols. Code
+  * lifted (with modifications) from pe-dll.c from ld */
+ 
+ static unsigned int
+ pe_get16 (abfd, where)
+      bfd *abfd;
+      int where;
+ {
+   unsigned char b[2];
+ 
+   bfd_seek (abfd, (file_ptr) where, SEEK_SET);
+   bfd_bread (b, (bfd_size_type) 2, abfd);
+   return b[0] + (b[1] << 8);
+ }
+ 
+ static unsigned int
+ pe_get32 (abfd, where)
+      bfd *abfd;
+      int where;
+ {
+   unsigned char b[4];
+ 
+   bfd_seek (abfd, (file_ptr) where, SEEK_SET);
+   bfd_bread (b, (bfd_size_type) 4, abfd);
+   return b[0] + (b[1] << 8) + (b[2] << 16) + (b[3] << 24);
+ }
+ 
+ static unsigned int
+ pe_as32 (ptr)
+      void *ptr;
+ {
+   unsigned char *b = ptr;
+ 
+   return b[0] + (b[1] << 8) + (b[2] << 16) + (b[3] << 24);
+ }
+ 
+ /* Read the (non-debug) export symbol table from a portable
+  * executable.  originally from the ld function pe_implied_import_dll
+  * from pe-dll.c */
+ 
+ static void read_pe_exported_syms (struct objfile *objfile)
+ {
+   bfd *dll = objfile->obfd;
+   unsigned long pe_header_offset, opthdr_ofs, num_entries, i;
+   unsigned long export_rva, export_size, nsections, secptr, expptr;
+   unsigned long exp_funcbase;
+   unsigned char *expdata, *erva;
+   unsigned long name_rvas, ordinals, nexp, ordbase;
+   char *dll_name;
+ 
+   /* Array elements are for text, data and bss in that order
+      Initialization with start_rva > end_rva guarantees that
+      unused sections won't be matched */
+   struct read_pe_section_data section_data[PE_SECTION_TABLE_SIZE]
+     = { {0, 1, 0, mst_text},
+ 	{0, 1, 0, mst_data},
+ 	{0, 1, 0, mst_bss} };
+ 
+   struct cleanup *back_to = 0;
+ 
+   /* Get pe_header, optional header and numbers of export entries.  */
+   pe_header_offset = pe_get32 (dll, 0x3c);
+   opthdr_ofs = pe_header_offset + 4 + 20;
+   num_entries = pe_get32 (dll, opthdr_ofs + 92);
+ 
+   if (num_entries < 1) /* No exports.  */
+     {
+       return;
+     }
+ 
+   export_rva = pe_get32 (dll, opthdr_ofs + 96);
+   export_size = pe_get32 (dll, opthdr_ofs + 100);
+   nsections = pe_get16 (dll, pe_header_offset + 4 + 2);
+   secptr = (pe_header_offset + 4 + 20 +
+ 	    pe_get16 (dll, pe_header_offset + 4 + 16));
+   expptr = 0;
+ 
+   /* Get the rva and size of the export section.  */ 
+   for (i = 0; i < nsections; i++)
+     {
+       char sname[8];
+       unsigned long secptr1 = secptr + 40 * i;
+       unsigned long vaddr = pe_get32 (dll, secptr1 + 12);
+       unsigned long vsize = pe_get32 (dll, secptr1 + 16);
+       unsigned long fptr = pe_get32 (dll, secptr1 + 20);
+ 
+       bfd_seek (dll, (file_ptr) secptr1, SEEK_SET);
+       bfd_bread (sname, (bfd_size_type) 8, dll);
+ 
+       if (vaddr <= export_rva && vaddr + vsize > export_rva)
+ 	{
+ 	  expptr = fptr + (export_rva - vaddr);
+ 	  if (export_rva + export_size > vaddr + vsize)
+ 	    export_size = vsize - (export_rva - vaddr);
+ 	  break;
+ 	}
+     }
+ 
+   if (export_size == 0)
+     {
+       /* Empty export table */
+       return;
+     }
+ 
+   /* Scan sections and store the base and size of the relevant sections */
+   for (i = 0; i < nsections; i++)
+     {
+       unsigned long secptr1 = secptr + 40 * i;
+       unsigned long vsize = pe_get32 (dll, secptr1 + 8);
+       unsigned long vaddr = pe_get32 (dll, secptr1 + 12);
+       unsigned long flags = pe_get32 (dll, secptr1 + 36);
+       char sec_name[9];
+       int sectix;
+ 
+       sec_name[8] = '\0';
+       bfd_seek (dll, (file_ptr) secptr1 + 0, SEEK_SET);
+       bfd_bread (sec_name, (bfd_size_type) 8, dll);
+ 
+       sectix = read_pe_section_index (sec_name);
+ 
+       if (sectix != PE_SECTION_INDEX_INVALID)
+ 	{
+ 	  section_data[sectix].rva_start = vaddr;
+ 	  section_data[sectix].rva_end = vaddr + vsize;
+ 	}
+     }
+ 
+   expdata = (unsigned char *) xmalloc (export_size);
+   back_to = make_cleanup (xfree, expdata);
+ 
+   bfd_seek (dll, (file_ptr) expptr, SEEK_SET);
+   bfd_bread (expdata, (bfd_size_type) export_size, dll);
+   erva = expdata - export_rva;
+ 
+   nexp = pe_as32 (expdata + 24);
+   name_rvas = pe_as32 (expdata + 32);
+   ordinals = pe_as32 (expdata + 36);
+   ordbase = pe_as32 (expdata + 16);
+   exp_funcbase = pe_as32 (expdata + 28);
+ 
+   /* Use internal dll name instead of full pathname */
+   dll_name = pe_as32 (expdata + 12) + erva;
+ 
+   bfd_map_over_sections (dll, get_section_vmas, section_data);
+ 
+   printf_filtered ("Minimal symbols from %s...", dll_name);
+   wrap_here ("");
+ 
+   /* Truncate name at first dot to avoid problems with the qualified
+      names we generate. Should maybe also convert to all lower case
+      for convenience on Windows */
+   read_pe_truncate_name (dll_name);
+ 
+   /* Iterate through the list of symbols.  */
+   for (i = 0; i < nexp; i++)
+     {
+       /* Pointer to the names vector.  */
+       unsigned long name_rva = pe_as32 (erva + name_rvas + i * 4);
+ 
+       /* Pointer to the function address vector.  */ 
+       unsigned long func_rva = pe_as32 (erva + exp_funcbase + i * 4);
+ 
+       /* Find this symbol's section in our own array */
+       int sectix = 0;
+ 
+       for (sectix = 0; sectix < PE_SECTION_TABLE_SIZE; ++sectix)
+ 	{
+ 	  if ((func_rva >= section_data[sectix].rva_start)
+ 	      && (func_rva < section_data[sectix].rva_end))
+ 	    {
+ 	      add_pe_exported_sym (erva + name_rva,
+ 				   func_rva,
+ 				   section_data + sectix,
+ 				   dll_name,
+ 				   objfile);
+ 	      break;
+ 	    }
+ 	}
+     }
+ 
+   /* discard expdata */
+   do_cleanups (back_to);
  }
  \f
  /* Support for string table handling */

Re: coffread.c extension for DLLs without debugging symbols

[Christopher Faylor]

On Mon, Jan 06, 2003 at 12:11:20PM -0500, Elena Zannoni wrote:
>About location of the code, add maybe a coff-pe-read.c? (ulgh) But
>since it deals with reading symbols, I would think it more logical to
>stay in some object/debug format related file rather than in a target
>related file.

Actually, this is a very good point since PE format is not limited to
just Windows, I believe.

cgf

Re: coffread.c extension for DLLs without debugging symbols

[Raoul Gough]

"Elena Zannoni" <ezannoni@redhat.com> wrote in message
news:15897.47288.570835.988631@localhost.redhat.com...
> I am including the plain text of the last version of the patch.
> I have noticed a few functions are using K&R style, please use ISO
C.
> Also the formatting for functions should be
>
> int
> foo (int par1, int par2)
>
> so that grep ^foo will work.

OK, this is no problem. In fact the K&R style functions are straight
out of pe-dll.c from ld, and I think there are existing bfd_ functions
that do the same thing. I'll fix the code to use the bfd functions
(removing the K&R style functions) and also sort out the other
formatting issues as well.

>
> (sorry, I have to ask) Do you have a copyright assignment with the
FSF?

No - I don't mind filling one out, though (at least I think I don't -
I haven't seen one yet :-). Can you email me one, please?

>
> As far as the new code being triggered, could you do it based on the
> existance of some particular section/data in the objfile?  I see
that
> you bail out of read_pe_exported_syms if there are no exports, could
> something on the same flavour be done? (like using bfd_get_flavour,
> or bfd_get_section_by_name, etc)

Not sure what you mean here - it currently uses both the pe_file flag
and bfd_get_target() to check whether to proceed with the processing.
I could also add a get_section_by_name(".edata") I guess.

>
> About location of the code, add maybe a coff-pe-read.c? (ulgh) But
> since it deals with reading symbols, I would think it more logical
to
> stay in some object/debug format related file rather than in a
target
> related file.

I agree - there will still have to be a hook in coffread to call the
new function, though. Does this also mean changing the config somehow
to make it compile the new module under the right circumstances? Any
advice on doing this?

Regards,
Raoul Gough.

>
> Elena
>
>
> Index: coffread.c
[snip]

Re: coffread.c extension for DLLs without debugging symbols

[Andrew Cagney]

> I am including the plain text of the last version of the patch.
> I have noticed a few functions are using K&R style, please use ISO C.
> Also the formatting for functions should be

[thanks]

[some times I hate my job :-)]

Raoul, looks like a little bit of paper work will be needed.  I'll 
follow up privatly.

Andrew

Re: coffread.c extension for DLLs without debugging symbols

[Raoul Gough]

"Christopher Faylor" <cgf@redhat.com> wrote in message
news:20030104205130.GA9784@redhat.com...
> On Sat, Jan 04, 2003 at 04:25:16PM -0000, Raoul Gough wrote:
> >"Christopher Faylor" <cgf@redhat.com> wrote in message
> >news:20030104044408.GA7364@redhat.com...
[snip]
> >>3) objdump -p already has the ability to read and report on the
export
> >>table.  I wonder if it would be useful (or possible) to generalize
this
> >>code so that gdb and objdump would be using the same base.  I
haven't
> >
> >I assumed that since ld did it the hard way, there wasn't any
proper
> >support for this in bfd - maybe that's not true. Obviously, sharing
> >this kind of code between code bases would be the ideal situation,
but
> >I don't think I've got enough of an overview to do that.
>
> Hmm.  You're right ld does it the hard way doesn't it?  Well, I
don't
> want to saddle you with one of those "The best way to deal with this
> is to redesign binutils, gcc, and awk so that it will all be
transparent
> to gdb" type of deals.  If you can find some kind of common ground
in
> bfd that ld, gdb, and objdump (and who knows, objcopy?) can all use
then
> that would be a huge win.  Otherwise your current plan is fine, IMO.

I've looked into the objdump code, and the relevant code in BFD seems
to be the function pe_print_edata which seems to originate in
peXXigen.c. Unfortunately, this just dumps the info in text form, and
doesn't provide any kind of iterator or callback interface. On the
other hand, the BFD code looks a lot cleaner than the stuff I got out
of ld, so I'm considering copying this code instead.

Of course it would be good to share the code, but this kind of thing
won't fit into the generic BFD interface. One possibility would be to
expose a platform-specific interface from within the BFD internals.
Can anyone suggest a BFD maintainer to talk to about this?

Regards,
Raoul Gough.

Re: coffread.c extension for DLLs without debugging symbols

[Daniel Jacobowitz]

On Tue, Jan 07, 2003 at 01:03:45AM -0000, Raoul Gough wrote:
> Of course it would be good to share the code, but this kind of thing
> won't fit into the generic BFD interface. One possibility would be to
> expose a platform-specific interface from within the BFD internals.
> Can anyone suggest a BFD maintainer to talk to about this?

That should be pretty easy.  Ask on binutils@sources.redhat.com.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: coffread.c extension for DLLs without debugging symbols

[Elena Zannoni]

Raoul Gough writes:
 > "Elena Zannoni" <ezannoni@redhat.com> wrote in message
 > news:15897.47288.570835.988631@localhost.redhat.com...
 > > I am including the plain text of the last version of the patch.
 > > I have noticed a few functions are using K&R style, please use ISO
 > C.
 > > Also the formatting for functions should be
 > >
 > > int
 > > foo (int par1, int par2)
 > >
 > > so that grep ^foo will work.
 > 
 > OK, this is no problem. In fact the K&R style functions are straight
 > out of pe-dll.c from ld, and I think there are existing bfd_ functions
 > that do the same thing. I'll fix the code to use the bfd functions
 > (removing the K&R style functions) and also sort out the other
 > formatting issues as well.
 > 
thanks

 > >
 > > (sorry, I have to ask) Do you have a copyright assignment with the
 > FSF?
 > 
 > No - I don't mind filling one out, though (at least I think I don't -
 > I haven't seen one yet :-). Can you email me one, please?
 > 

done, i think.

 > >
 > > As far as the new code being triggered, could you do it based on the
 > > existance of some particular section/data in the objfile?  I see
 > that
 > > you bail out of read_pe_exported_syms if there are no exports, could
 > > something on the same flavour be done? (like using bfd_get_flavour,
 > > or bfd_get_section_by_name, etc)
 > 
 > Not sure what you mean here - it currently uses both the pe_file flag
 > and bfd_get_target() to check whether to proceed with the processing.
 > I could also add a get_section_by_name(".edata") I guess.
 > 

Usually gdb triggers reading one debug format or another depending on
the presence of certain sections names. So here, instead of looking at
the target you can look at the existance of .edata.

Look at elfread.c and how it finds which debug format is used.  It is
not using get_section_by_name(), but the idea is similar.

 > >
 > > About location of the code, add maybe a coff-pe-read.c? (ulgh) But
 > > since it deals with reading symbols, I would think it more logical
 > to
 > > stay in some object/debug format related file rather than in a
 > target
 > > related file.
 > 
 > I agree - there will still have to be a hook in coffread to call the
 > new function, though. Does this also mean changing the config somehow
 > to make it compile the new module under the right circumstances? Any
 > advice on doing this?
 > 

No, I just meant that the functions to manipulate these symbols could
be moved into their own file. Gdb always includes all the
debug/objfile readers in each build, so no need to tweak configure.

Elena

Re: coffread.c extension for DLLs without debugging symbols

[Michael Snyder]

Christopher Faylor wrote:
> 
> On Fri, Jan 03, 2003 at 07:39:31PM -0000, Raoul Gough wrote:
> >Proposed ChangeLog entry, assuming the code is accepted:
> >
> >2003-01-03  Raoul Gough  <RaoulGough@yahoo.co.uk>
> >
> > * coffread.c: Support non-debug export symbols for win32 DLLs
> 
> WONDERFUL! I would love to have this code in the windows version of gdb.
> I've often thought about doing something like this but I've never had
> the stamina to look into what it would take to do this.
> 
> I have a few comments.
> 
> 0) The ChangeLog needs more information.  Every new function should be
> mentioned and changes to specific functions should be documented.
> 
> 1) AFAICT, the formatting of the code looks great (a rarity for a first
> timer) except for an odd comment or two which doesn't end in a "." as
> required for a complete sentence.  Yeah, yeah, a total nit but hey we've
> got standards!
> 
> 2) I wonder if this code should be ifdef'ed somehow for Windows since
> it will add extra code for no gain on every COFF platform.  Of course,
> how many of those are there out there?  Maybe this isn't a huge issue
> after all.

Geez, we include EVERY objfile reader on EVERY platform.
Adding a little code to one vanishes into the noise!

> 
> 3) objdump -p already has the ability to read and report on the export
> table.  I wonder if it would be useful (or possible) to generalize this
> code so that gdb and objdump would be using the same base.  I haven't
> looked too closely but I think the code in question is in bfd/peicode.h.
> Hmm.  Maybe objdump isn't interested in the kinds of things that gdb
> is, though, like what section a symbol is associated with...
> 
> Anyway, I'll be giving this an actual test run in the next couple of
> days.  In the meantime, THANK YOU for doing this.  Even given the very
> minor above points, I think this will be a great boon for the Windows
> version of gdb.  This will help enormously in debugging on Windows.
> 
> You will definitely need to get an assignment in to the FSF, though,
> unfortunately.  I think jimb at redhat dot com is the person to help
> you with that.
> 
> cgf
> 
> P.S.  Assuming that this works as advertised, I assume that you will
> have no objections to my releasing a new version of gdb for windows
> with this patch in it before the patch makes its way into the official
> gdb repository, right?  I think there are a few users in the cygwin
> mailing list that would appreciate this change.
> --
> Special for spam email harvesters: send email to aaaspam@sources.redhat.com
> and be permanently blocked from mailing lists at sources.redhat.com.

Re: coffread.c extension for DLLs without debugging symbols

[Michael Snyder]

Raoul Gough wrote:

> > Special for spam email harvesters: send email to
> aaaspam@sources.redhat.com
> > and be permanently blocked from mailing lists at sources.redhat.com.
> 
> Alright! Sock it to 'em, redhat!

Sock it to 'em, CGF.  Red Hat just loans us the space.

Re: coffread.c extension for DLLs without debugging symbols

[Raoul Gough]

[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]

"Christopher Faylor" <cgf@redhat.com> wrote in message
news:20030104205130.GA9784@redhat.com...
> On Sat, Jan 04, 2003 at 04:25:16PM -0000, Raoul Gough wrote:
> >"Christopher Faylor" <cgf@redhat.com> wrote in message
> >news:20030104044408.GA7364@redhat.com...
> >> P.S.  Assuming that this works as advertised, I assume that you
will
> >> have no objections to my releasing a new version of gdb for
windows
> >> with this patch in it before the patch makes its way into the
official
> >> gdb repository, right?  I think there are a few users in the
cygwin
> >> mailing list that would appreciate this change.
> >
> >By all means - please do. You may as well use the new diff for the
> >comment fixes and the strncmp business.
>
> Ok.  Coming soon to a cygwin mirror near you.

Chris, I've done some more testing and discovered a problem with the
virtual memory address determination mechanism. I've been using
bfd_get_section_vma to find out where each section is in memory, but
this is not always correct. BFD returns the DLL's *preferred* load
address, but it may actually have been relocated during loading
because of address space clashes. It seems obvious now, but BFD is not
the right place to get the needed information. I'm looking into the
win32-nat code that handles DLL load events, which *does* know about
the real load address. Unfortunately, this really will make the code
win32 specific. Unless someone else can suggest anything better?

Actually, this seems like a generic bug in GDB's DLL handling - by
compiling with debugging symbols, the problem is even visible without
my patch. Have a look at the attached example, which shows GDB 5.2.1
getting it wrong.

Regards,
Raoul Gough.


[-- Attachment #2: example2.txt --]
[-- Type: text/plain, Size: 2962 bytes --]

$ cat dlleg.c
__attribute((__dllexport__)) void fn () { }
__attribute((__dllexport__)) char hello[] = "Hello world";
__attribute((__dllexport__)) int init_data = 42;
__attribute((__dllexport__)) int uninit_data;
$ cat dlleg2.c
__attribute((__dllexport__)) void fn2 () { }
__attribute((__dllexport__)) char hello2[] = "Hello again";
__attribute((__dllexport__)) int init_data2 = 44;
__attribute((__dllexport__)) int uninit_data2;
$ cat dllegmain.c
__attribute((__dllimport__)) void fn ();
__attribute((__dllimport__)) char hello[];
__attribute((__dllimport__)) int init_data;
__attribute((__dllimport__)) int uninit_data;

__attribute((__dllimport__)) void fn2 ();
__attribute((__dllimport__)) char hello2[];
__attribute((__dllimport__)) int init_data2;
__attribute((__dllimport__)) int uninit_data2;

int main ()
{
  fn();
  uninit_data = init_data;

  fn2();
  uninit_data2 = init_data2;

  return 0;
}
$ gcc -g -c dlleg.c
$ gcc -g -c dlleg2.c
$ gcc -g -c dllegmain.c
$ #
$ # Note - by omitting the --enable-auto-image-base linker flag, both
$ # DLLs get the same load address by default (0x1000000). At load
$ # time, one of them gets relocated
$ #
$ gcc -shared -o dlleg.dll dlleg.o
$ gcc -shared -o dlleg2.dll dlleg2.o
$ gcc -o dllegmain dllegmain.o dlleg.dll dlleg2.dll
$ gdb dllegmain
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "mingw32"...
(gdb) break main
Breakpoint 1 at 0x401050: file dllegmain.c, line 13.
(gdb) run
Starting program: f:\Users\Raoul\gdb/dllegmain.exe 

Breakpoint 1, main () at dllegmain.c:13
13	  fn();
(gdb) x/s &hello
0x10002000 <hello2>:	 "Hello again"
(gdb) #
(gdb) # Uh oh. The symbol "hello" should point to the string
(gdb) # "Hello world", and hello2 should be "Hello again"
(gdb) # (see dlleg.c and dlleg2.c above)
(gdb) #
(gdb) x/s &hello2
0x10002000 <hello2>:	 "Hello again"
(gdb) #
(gdb) # win32-nat.c knows the real load addresses:
(gdb) #
(gdb) info dll
DLL Name                        Load Address
F:\cygwin\bin\cygwin1.dll       61001000
F:\WINNT\system32\kernel32.dll  77e81000
f:\Users\Raoul\gdb\dlleg2.dll   10001000
f:\Users\Raoul\gdb\dlleg.dll    00331000
F:\WINNT\system32\advapi32.dll  77db1000
F:\WINNT\system32\rpcrt4.dll    77d41000
F:\WINNT\system32\user32.dll    77e11000
F:\WINNT\system32\gdi32.dll     77f41000
(gdb) #
(gdb) # Using this information, we can find the other string
(gdb) # manually. dlleg2.dll got loaded at it's preferred
(gdb) # address, but dlleg.dll was relocated.
(gdb) #
(gdb) x/s 0x332000
0x332000:	 "Hello world"
(gdb) quit
The program is running.  Exit anyway? (y or n) y
$ 

Re: coffread.c extension for DLLs without debugging symbols

[Christopher Faylor]

[Reply-To set to mailing list]
On Tue, Jan 07, 2003 at 01:10:49PM -0000, Raoul Gough wrote:
>Actually, this seems like a generic bug in GDB's DLL handling - by
>compiling with debugging symbols, the problem is even visible without
>my patch. Have a look at the attached example, which shows GDB 5.2.1
>getting it wrong.

This should be fixed in current CVS and in gdb 5.3.

cgf

Re: coffread.c extension for DLLs without debugging symbols

[Raoul Gough]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

"Andrew Cagney" <ac131313@redhat.com> wrote in message
news:3E1A2656.7080906@redhat.com...
> Raoul, looks like a little bit of paper work will be needed.  I'll
> follow up privatly.

The paperwork is reportedly on its way to me now. I've since got a new
version of the patch together, which introduces coff-pe-read.c. I'm
pretty sure I've got the Makefile right - I added coff-pe-read.o to
both SFILES and COMMON_OBS since they already involved coffread.o
(anything that needs coffread.o now also needs coff-pe-read.o).

I've also fixed the problem with relocated DLLs, and AFAIK all
formatting issues. The maintainer will have to add the FSF copyright
notices, since I suppose the FSF doesn't acknowledge ownership until
the forms go through. I guess you also can't put any of this in CVS
until the forms have been processed?

BTW, I have some more patches on the way, because I've found what some
problems with the general handling of DLL relocation on Windows. I'll
post these separately when they're ready.

Regards,
Raoul Gough.

[-- Attachment #2: ChangeLog_entry.txt --]
[-- Type: text/plain, Size: 506 bytes --]

2003-01-10  Raoul Gough  <RaoulGough@yahoo.co.uk>

	* coff-pe-read.c: New file - support reading of minimal symbols
	from a portable executable using the export table.
	* coff-pe-read.h: New file
	* coffread.c: #include coff-pe-read.h
	(coff_symtab_read): call read_pe_exported_syms iff no recognized
	debugging symbols found.
	* Makefile.in (SFILES): add coff-pe-read.o
	(coff_pe_read_h): define
	(COMMON_OBS): add coff-pe-read.o
	(coffread.o): add coff_pe_read_h dependency
	(coff-pe-read.o): New target

[-- Attachment #3: coff-pe-read.h --]
[-- Type: application/octet-stream, Size: 394 bytes --]

/* Interface to coff-pe-read.c (portable-executable-specific symbol reader).

   Contributed by Raoul M. Gough (RaoulGough@yahoo.co.uk). */

#if !defined (COFF_PE_READ_H)
#define COFF_PE_READ_H

struct objfile;

/* Read the export table and convert it to minimal symbol table entries */
void read_pe_exported_syms (struct objfile *objfile);

#endif /* !defined (COFF_PE_READ_H) */

[-- Attachment #4: coff-pe-read.c --]
[-- Type: application/octet-stream, Size: 9599 bytes --]

/* Read the export table symbols from a portable executable and
   convert to internal format, for GDB. Used as a last resort if no
   debugging symbols recognized.

   Contributed by Raoul M. Gough (RaoulGough@yahoo.co.uk). */

#include "coff-pe-read.h"

#include "bfd.h"

#include "defs.h"
#include "gdbtypes.h"

#include "symtab.h"
#include "symfile.h"
#include "objfiles.h"

/* Internal section information */

struct read_pe_section_data
{
  CORE_ADDR vma_offset;               /* Offset to loaded address of section.*/
  unsigned long rva_start;            /* Start offset within the pe. */
  unsigned long rva_end;              /* End offset within the pe. */
  enum minimal_symbol_type ms_type;   /* Type to assign symbols in section. */
};

#define PE_SECTION_INDEX_TEXT     0
#define PE_SECTION_INDEX_DATA     1
#define PE_SECTION_INDEX_BSS      2
#define PE_SECTION_TABLE_SIZE     3
#define PE_SECTION_INDEX_INVALID -1
\f
/* Get the index of the named section in our own array, which contains
   text, data and bss in that order. Return PE_SECTION_INDEX_INVALID
   if passed an unrecognised section name. */

static int
read_pe_section_index (const char *section_name)
{
  if (strcmp (section_name, ".text") == 0)
    {
      return PE_SECTION_INDEX_TEXT;
    }

  else if (strcmp (section_name, ".data") == 0)
    {
      return PE_SECTION_INDEX_DATA;
    }

  else if (strcmp (section_name, ".bss") == 0)
    {
      return PE_SECTION_INDEX_BSS;
    }

  else
    {
      return PE_SECTION_INDEX_INVALID;
    }
}

/* Record the virtual memory address of a section. */

static void
get_section_vmas (bfd *abfd, asection *sectp, void *context)
{
  struct read_pe_section_data *sections = context;
  int sectix = read_pe_section_index (sectp->name);

  if (sectix != PE_SECTION_INDEX_INVALID)
    {
      /* Data within the section start at rva_start in the pe and at
         bfd_get_section_vma() within memory. Store the offset. */

      sections[sectix].vma_offset
	= bfd_get_section_vma (abfd, sectp) - sections[sectix].rva_start;
    }
}
\f
/* Create a minimal symbol entry for an exported symbol. */

static void
add_pe_exported_sym (char *sym_name,
		     unsigned long func_rva,
		     const struct read_pe_section_data *section_data,
		     const char *dll_name,
		     struct objfile *objfile)
{
  /* Add the stored offset to get the loaded address of the symbol. */

  CORE_ADDR vma = func_rva + section_data->vma_offset;

  char *qualified_name = 0;
  int dll_name_len = strlen (dll_name);
  int count;

  /* Generate a (hopefully unique) qualified name using the first part
     of the dll name, e.g. KERNEL32!AddAtomA. This matches the style
     used by windbg from the "Microsoft Debugging Tools for Windows". */

  qualified_name = xmalloc (dll_name_len + strlen (sym_name) + 2);

  strncpy (qualified_name, dll_name, dll_name_len);
  qualified_name[dll_name_len] = '!';
  strcpy (qualified_name + dll_name_len + 1, sym_name);

  prim_record_minimal_symbol (qualified_name,
			      vma,
			      section_data->ms_type,
			      objfile);

  xfree (qualified_name);

  /* Enter the plain name as well, which might not be unique. */
  prim_record_minimal_symbol (sym_name,
			      vma,
			      section_data->ms_type,
			      objfile);
}

/* Truncate a dll_name at the first dot character. */

static void
read_pe_truncate_name (char *dll_name)
{
  while (*dll_name)
    {
      if ((*dll_name) == '.')
	{
	  *dll_name = '\0'; /* truncates and causes loop exit. */
	}

      else
	{
	  ++dll_name;
	}
    }
}
\f
/* Low-level support functions, direct from the ld module pe-dll.c. */
static unsigned int
pe_get16 (bfd *abfd, int where)
{
  unsigned char b[2];

  bfd_seek (abfd, (file_ptr) where, SEEK_SET);
  bfd_bread (b, (bfd_size_type) 2, abfd);
  return b[0] + (b[1] << 8);
}

static unsigned int
pe_get32 (bfd *abfd, int where)
{
  unsigned char b[4];

  bfd_seek (abfd, (file_ptr) where, SEEK_SET);
  bfd_bread (b, (bfd_size_type) 4, abfd);
  return b[0] + (b[1] << 8) + (b[2] << 16) + (b[3] << 24);
}

static unsigned int
pe_as32 (void *ptr)
{
  unsigned char *b = ptr;

  return b[0] + (b[1] << 8) + (b[2] << 16) + (b[3] << 24);
}
\f
/* Read the (non-debug) export symbol table from a portable
   executable. Code originally lifted from the ld function
   pe_implied_import_dll in pe-dll.c. */

void
read_pe_exported_syms (struct objfile *objfile)
{
  bfd *dll = objfile->obfd;
  unsigned long pe_header_offset, opthdr_ofs, num_entries, i;
  unsigned long export_rva, export_size, nsections, secptr, expptr;
  unsigned long exp_funcbase;
  unsigned char *expdata, *erva;
  unsigned long name_rvas, ordinals, nexp, ordbase;
  char *dll_name;

  /* Array elements are for text, data and bss in that order
     Initialization with start_rva > end_rva guarantees that
     unused sections won't be matched. */
  struct read_pe_section_data section_data[PE_SECTION_TABLE_SIZE]
    = { {0, 1, 0, mst_text},
	{0, 1, 0, mst_data},
	{0, 1, 0, mst_bss} };

  struct cleanup *back_to = 0;

  char const *target = bfd_get_target (objfile->obfd);

  if ((strcmp (target, "pe-i386") != 0) && (strcmp (target, "pei-i386") != 0))
    {
      /* This is not an i386 format file. Abort now, because the code
	 is untested on anything else. *FIXME* test on further
	 architectures and loosen or remove this test. */
      return;
    }

  /* Get pe_header, optional header and numbers of export entries.  */
  pe_header_offset = pe_get32 (dll, 0x3c);
  opthdr_ofs = pe_header_offset + 4 + 20;
  num_entries = pe_get32 (dll, opthdr_ofs + 92);

  if (num_entries < 1) /* No exports.  */
    {
      return;
    }

  export_rva = pe_get32 (dll, opthdr_ofs + 96);
  export_size = pe_get32 (dll, opthdr_ofs + 100);
  nsections = pe_get16 (dll, pe_header_offset + 4 + 2);
  secptr = (pe_header_offset + 4 + 20 +
	    pe_get16 (dll, pe_header_offset + 4 + 16));
  expptr = 0;

  /* Get the rva and size of the export section.  */ 
  for (i = 0; i < nsections; i++)
    {
      char sname[8];
      unsigned long secptr1 = secptr + 40 * i;
      unsigned long vaddr = pe_get32 (dll, secptr1 + 12);
      unsigned long vsize = pe_get32 (dll, secptr1 + 16);
      unsigned long fptr = pe_get32 (dll, secptr1 + 20);

      bfd_seek (dll, (file_ptr) secptr1, SEEK_SET);
      bfd_bread (sname, (bfd_size_type) 8, dll);

      if (vaddr <= export_rva && vaddr + vsize > export_rva)
	{
	  expptr = fptr + (export_rva - vaddr);
	  if (export_rva + export_size > vaddr + vsize)
	    export_size = vsize - (export_rva - vaddr);
	  break;
	}
    }

  if (export_size == 0)
    {
      /* Empty export table. */
      return;
    }

  /* Scan sections and store the base and size of the relevant sections. */
  for (i = 0; i < nsections; i++)
    {
      unsigned long secptr1 = secptr + 40 * i;
      unsigned long vsize = pe_get32 (dll, secptr1 + 8);
      unsigned long vaddr = pe_get32 (dll, secptr1 + 12);
      unsigned long flags = pe_get32 (dll, secptr1 + 36);
      char sec_name[9];
      int sectix;

      sec_name[8] = '\0';
      bfd_seek (dll, (file_ptr) secptr1 + 0, SEEK_SET);
      bfd_bread (sec_name, (bfd_size_type) 8, dll);

      sectix = read_pe_section_index (sec_name);

      if (sectix != PE_SECTION_INDEX_INVALID)
	{
	  section_data[sectix].rva_start = vaddr;
	  section_data[sectix].rva_end = vaddr + vsize;
	}
    }

  expdata = (unsigned char *) xmalloc (export_size);
  back_to = make_cleanup (xfree, expdata);

  bfd_seek (dll, (file_ptr) expptr, SEEK_SET);
  bfd_bread (expdata, (bfd_size_type) export_size, dll);
  erva = expdata - export_rva;

  nexp = pe_as32 (expdata + 24);
  name_rvas = pe_as32 (expdata + 32);
  ordinals = pe_as32 (expdata + 36);
  ordbase = pe_as32 (expdata + 16);
  exp_funcbase = pe_as32 (expdata + 28);

  /* Use internal dll name instead of full pathname. */
  dll_name = pe_as32 (expdata + 12) + erva;

  bfd_map_over_sections (dll, get_section_vmas, section_data);

  /* Adjust the vma_offsets in case this PE got relocated. This
     assumes that *all* sections share the same relocation offset
     as the text section. */
  for (i = 0; i < PE_SECTION_TABLE_SIZE; i++)
    {
      section_data[i].vma_offset
	+= ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
    }

  printf_filtered ("Minimal symbols from %s...", dll_name);
  wrap_here ("");

  /* Truncate name at first dot. Should maybe also convert to all
     lower case for convenience on Windows. */
  read_pe_truncate_name (dll_name);

  /* Iterate through the list of symbols.  */
  for (i = 0; i < nexp; i++)
    {
      /* Pointer to the names vector.  */
      unsigned long name_rva = pe_as32 (erva + name_rvas + i * 4);

      /* Pointer to the function address vector.  */ 
      unsigned long func_rva = pe_as32 (erva + exp_funcbase + i * 4);

      /* Find this symbol's section in our own array. */
      int sectix = 0;

      for (sectix = 0; sectix < PE_SECTION_TABLE_SIZE; ++sectix)
	{
	  if ((func_rva >= section_data[sectix].rva_start)
	      && (func_rva < section_data[sectix].rva_end))
	    {
	      add_pe_exported_sym (erva + name_rva,
				   func_rva,
				   section_data + sectix,
				   dll_name,
				   objfile);
	      break;
	    }
	}
    }

  /* discard expdata. */
  do_cleanups (back_to);
}




[-- Attachment #5: Makefile.in.diff --]
[-- Type: application/octet-stream, Size: 3073 bytes --]

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.310
diff -c -p -r1.310 Makefile.in
*** Makefile.in	6 Jan 2003 20:45:30 -0000	1.310
--- Makefile.in	10 Jan 2003 22:32:08 -0000
*************** SFILES = ada-exp.y ada-lang.c ada-typepr
*** 501,507 ****
  	ax-general.c ax-gdb.c \
  	bcache.c blockframe.c breakpoint.c buildsym.c builtin-regs.c \
  	c-exp.y c-lang.c c-typeprint.c c-valprint.c \
! 	charset.c cli-out.c coffread.c complaints.c completer.c corefile.c \
  	cp-abi.c cp-support.c cp-valprint.c \
  	dbxread.c demangle.c disasm.c doublest.c \
  	dummy-frame.c dwarfread.c dwarf2read.c \
--- 501,508 ----
  	ax-general.c ax-gdb.c \
  	bcache.c blockframe.c breakpoint.c buildsym.c builtin-regs.c \
  	c-exp.y c-lang.c c-typeprint.c c-valprint.c \
! 	charset.c cli-out.c coffread.c coff-pe-read.c \
! 	complaints.c completer.c corefile.c \
  	cp-abi.c cp-support.c cp-valprint.c \
  	dbxread.c demangle.c disasm.c doublest.c \
  	dummy-frame.c dwarfread.c dwarf2read.c \
*************** call_cmds_h = call-cmds.h
*** 598,603 ****
--- 599,605 ----
  ch_lang_h = ch-lang.h
  cli_out_h = cli-out.h
  coff_solib_h = coff-solib.h
+ coff_pe_read_h = coff-pe-read.h
  command_h = command.h
  complaints_h = complaints.h
  completer_h = completer.h
*************** COMMON_OBS = version.o blockframe.o brea
*** 817,823 ****
  	kod.o kod-cisco.o \
  	gdb-events.o \
  	exec.o bcache.o objfiles.o minsyms.o maint.o demangle.o \
! 	dbxread.o coffread.o elfread.o \
  	dwarfread.o dwarf2read.o mipsread.o stabsread.o corefile.o \
  	c-lang.o f-lang.o \
  	ui-out.o cli-out.o \
--- 819,825 ----
  	kod.o kod-cisco.o \
  	gdb-events.o \
  	exec.o bcache.o objfiles.o minsyms.o maint.o demangle.o \
! 	dbxread.o coffread.o coff-pe-read.o elfread.o \
  	dwarfread.o dwarf2read.o mipsread.o stabsread.o corefile.o \
  	c-lang.o f-lang.o \
  	ui-out.o cli-out.o \
*************** coffread.o: coffread.c $(defs_h) $(symta
*** 1570,1576 ****
  	$(breakpoint_h) $(bfd_h) $(gdb_obstack_h) $(gdb_string_h) \
  	$(coff_internal_h) $(libcoff_h) $(symfile_h) $(objfiles_h) \
  	$(buildsym_h) $(gdb_stabs_h) $(stabsread_h) $(complaints_h) \
! 	$(target_h) $(gdb_assert_h)
  complaints.o: complaints.c $(defs_h) $(complaints_h) $(gdb_assert_h) \
  	$(command_h) $(gdbcmd_h)
  completer.o: completer.c $(defs_h) $(symtab_h) $(gdbtypes_h) $(expression_h) \
--- 1572,1580 ----
  	$(breakpoint_h) $(bfd_h) $(gdb_obstack_h) $(gdb_string_h) \
  	$(coff_internal_h) $(libcoff_h) $(symfile_h) $(objfiles_h) \
  	$(buildsym_h) $(gdb_stabs_h) $(stabsread_h) $(complaints_h) \
! 	$(target_h) $(gdb_assert_h) $(coff_pe_read_h)
! coff-pe-read.o: coff-pe-read.c $(bfd_h) $(defs_h) $(symtab_h) \
! 	$(gdbtypes_h) $(symfile_h) $(objfiles_h) $(coff_pe_read_h)
  complaints.o: complaints.c $(defs_h) $(complaints_h) $(gdb_assert_h) \
  	$(command_h) $(gdbcmd_h)
  completer.o: completer.c $(defs_h) $(symtab_h) $(gdbtypes_h) $(expression_h) \

[-- Attachment #6: coffread.c.diff --]
[-- Type: application/octet-stream, Size: 882 bytes --]

Index: coffread.c
===================================================================
RCS file: /cvs/src/src/gdb/coffread.c,v
retrieving revision 1.32
diff -c -p -r1.32 coffread.c
*** coffread.c	17 Dec 2002 00:39:07 -0000	1.32
--- coffread.c	10 Jan 2003 22:33:35 -0000
***************
*** 45,50 ****
--- 45,52 ----
  #include "target.h"
  #include "gdb_assert.h"
  
+ #include "coff-pe-read.h"
+ 
  extern void _initialize_coffread (void);
  
  struct coff_symfile_info
*************** coff_symtab_read (long symtab_offset, un
*** 1084,1089 ****
--- 1086,1098 ----
  	  process_coff_symbol (cs, &main_aux, objfile);
  	  break;
  	}
+     }
+ 
+   if ((nsyms == 0) && (pe_file))
+     {
+       /* We've got no debugging symbols, but it's is a portable
+ 	 executable, so try to read the export table */
+       read_pe_exported_syms (objfile);
      }
  
    if (last_source_file)

Re: coffread.c extension for DLLs without debugging symbols

[Raoul Gough]

"Elena Zannoni" <ezannoni@redhat.com> wrote in message
news:15898.13355.611979.991969@localhost.redhat.com...
> Raoul Gough writes:

>  > OK, this is no problem. In fact the K&R style functions are
straight
>  > out of pe-dll.c from ld, and I think there are existing bfd_
functions
>  > that do the same thing. I'll fix the code to use the bfd
functions
>  > (removing the K&R style functions) and also sort out the other
>  > formatting issues as well.
>  >
> thanks

Actually, I've left those functions in after all, but reformatted
them. Turns out that the bfd_ functions are different enough that I
didn't want to try the change (if it's not broken....).

[snip]
>  > > As far as the new code being triggered, could you do it based
on the
>  > > existance of some particular section/data in the objfile?  I
see
>  > that
>  > > you bail out of read_pe_exported_syms if there are no exports,
could
>  > > something on the same flavour be done? (like using
bfd_get_flavour,
>  > > or bfd_get_section_by_name, etc)
>  >
>  > Not sure what you mean here - it currently uses both the pe_file
flag
>  > and bfd_get_target() to check whether to proceed with the
processing.
>  > I could also add a get_section_by_name(".edata") I guess.
>  >
>
> Usually gdb triggers reading one debug format or another depending
on
> the presence of certain sections names. So here, instead of looking
at
> the target you can look at the existance of .edata.
>
> Look at elfread.c and how it finds which debug format is used.  It
is
> not using get_section_by_name(), but the idea is similar.

I've decided to stick with the bfd_get_target, because I'd like to
make sure that the code only attempts to process i386 PE files (it
might work on, say, Alpha, but I can't test it). I'm sure there are
other ways to check this, but coffread.c already uses the target name
to set up the pe_file flag.

Note also that the .edata section can be empty (seems to happen with
.exe files).

>
>  > >
>  > > About location of the code, add maybe a coff-pe-read.c? (ulgh)
But
>  > > since it deals with reading symbols, I would think it more
logical
>  > to
>  > > stay in some object/debug format related file rather than in a
>  > target
>  > > related file.
>  >
>  > I agree - there will still have to be a hook in coffread to call
the
>  > new function, though. Does this also mean changing the config
somehow
>  > to make it compile the new module under the right circumstances?
Any
>  > advice on doing this?
>  >
>
> No, I just meant that the functions to manipulate these symbols
could
> be moved into their own file. Gdb always includes all the
> debug/objfile readers in each build, so no need to tweak configure.

coff-pe-read it is (see my other posting for the new patches).

Regards,
Raoul Gough.

Re: coffread.c extension for DLLs without debugging symbols

[Andrew Cagney]

> 
> "RFA" == "Request for Approval".
> 
> GDB has a human approval system that goes beyond the CVS permissions.
> You can read about it in the top level MAINTAINERS file.
> 
> There are three levels of access.  'Blanket Maintainers' have the
> authority to commit files anywhere in the gdb tree.  Several types
> of 'Maintainers' have authority to commit files in their area of
> responsibility.  'Write After Approval' maintainers have the authority
> to commit their patches if a Blanket Maintainer or a Maintainer approves
> them.

Almost.  A so-called blanket write maintainer, can not commit without 
approval (except where pretty obvious or pre-negotiated) a change to 
something that has a more specific maintainer.

Andrew

Re: coffread.c extension for DLLs without debugging symbols

[Michael Elizabeth Chastain]

Hi Raoul,

> What does RFA stand for? Seemed to me like it was used by people who
> were actually capable of updating the CVS themselves and just wanted
> confirmation.

"RFA" == "Request for Approval".

GDB has a human approval system that goes beyond the CVS permissions.
You can read about it in the top level MAINTAINERS file.

There are three levels of access.  'Blanket Maintainers' have the
authority to commit files anywhere in the gdb tree.  Several types
of 'Maintainers' have authority to commit files in their area of
responsibility.  'Write After Approval' maintainers have the authority
to commit their patches if a Blanket Maintainer or a Maintainer approves
them.

All of these people have write permission in the CVS repository.
If someone exceeds their authority and commits a patch without the
necessary authority, then the Head Maintainer would deal with them
and with their unauthorized commit.  This does not happen very often.

Many maintainers, even Blanket Maintainers, ask for RFA on patches
that they have the authority to commit.  If there is an active
Maintainer for an area, it's a smart move to get the Maintainer's
opinion before commiting to that area.

Other request types are:

  RFC == "request for comments".  The submitter wants feedback on the
  patch and may not even want to commit it yet.

  RFA == "request for approval".  The submitter has little doubt that
  the patch is ready to commit, and just wants a short answer.

  PATCH == "it's going in".  The submitter has authority to commit
  this patch and is about to do so, either immediately or as soon as
  they get around to it.  No reply is needed.

Michael Snyder knows the nuances of this system better than I do;
he may have some corrections.

I just filed a PR to document this stuff for the benefit of first-time
patch writers.

Michael C